<html>
    <head>
      <base href="https://bugs.freedesktop.org/" />
    </head>
    <body>
      <p>
        <div>
            <b><a class="bz_bug_link 
          bz_status_NEW "
   title="NEW - [Patch] VIARestore function improvement"
   href="https://bugs.freedesktop.org/show_bug.cgi?id=93243#c5">Comment # 5</a>
              on <a class="bz_bug_link 
          bz_status_NEW "
   title="NEW - [Patch] VIARestore function improvement"
   href="https://bugs.freedesktop.org/show_bug.cgi?id=93243">bug 93243</a>
              from <span class="vcard"><a class="email" href="mailto:mrugiero@gmail.com" title="Mario Rugiero <mrugiero@gmail.com>"> <span class="fn">Mario Rugiero</span></a>
</span></b>
        <pre>I'm with you about the comments, both in style (C89 comments, since just a
little comfort in the comments is not a good reason to drop standard C89
support) and content (we are lacking a lot of info in the driver).
On the return type style, while I consider it ugly, there are a few things
about it that tend to justify keeping it.
First, several system-level projects use that style (sections of the Linux
kernel do, for example, as most of X.org AFAIR), so the argument that it is not
common isn't really that strong.
Second, consistence matter. A good style is twice as good if it is consistent,
but a bad style is twice as bad if it is not. This may be a bad style, but
unless we first do a separate (so we don't mask actual functional changes)
commit fixing it, we'll make it worse if we use the "right" style here and
there, and the "wrong" style everywhere else. Your mind will automate how to
interpret the structure of text if it is consistent. This automation will be
broken if it isn't.
Third, it allows for longer, more descriptive return types without hurting
readability too much. Again, your eyes get used to the fact function signatures
are at least two lines long, but it won't get used to the fact that randomly
sometimes you need to scroll right and sometimes you don't.
Fourth, the more you highlight the important concepts, the more clear the
meaning of the code is, and certainly the return type of a function is
important, and certainly having its own line highlights it.
Aesthetically, I hate that style. But it does have some advantages that should
be weighted out.
Lastly, I suggest we keep conceptually different patches separate from each
other. You can make them depend on each other, but a single huge patch is
always a future problem. We should make stylistic changes in one patchset,
organized by style issue cleaned or by file touched (not both at the same
time), bugfixes one per patch, features on their own patchset, one per patch.
That's what I believe to be common sense.</pre>
        </div>
      </p>
      <hr>
      <span>You are receiving this mail because:</span>
      
      <ul>
          <li>You are the assignee for the bug.</li>
      </ul>
    </body>
</html>