:        ...
:Instead of:
:if (foo)
:        ...
:However, the real pain here is that basically people go and modify code
:they aren't even touching.  If you are modifying the condition of an if()
:but not the body then the extra braces are just gratuitous.  You did this
:when you went and pushed down Giant in a bunch of the syscalls adding {}'s
:around code you weren't directly touching.  Basically then it is rather
:tempting to just back them back out again in the next commit to that area
:of the code and we keep cycling back and forth which is pretty stupid.
:I would just prefer that we leave code as it is unless we actually require
:the extra braces because there are multiple statements in the body.  If
:you will commit to that I will commit to not removing extra braces that
:offend my sensibilities in my commits. :)
:John Baldwin <[EMAIL PROTECTED]>  <><  http://www.FreeBSD.org/~jhb/
:"Power Users Use the Power to Serve!"  -  http://www.FreeBSD.org/

   I will adjust bracing on code that I am working on.  It is hardly 
   gratuitous.  It makes it far easier for me to read and that's important
   because I don't like to miss things in the code I'm working on.

   You seem to think that the 'wasted vertical space' is a bad thing, as if
   human beings are, what, compilers?  We are human beings.  It is far more
   important for the code to well commented and readable, not squeezed
   together like a jack in the box in a way that only the original author
   can parse.  It does not make anyone's life easier trying to read 
   uncommented third party code and it certainly does not give one a
   quicker understanding of a piece of code just because its been squeezed
   together to all fit on one screen.  I find squeezed code to be almost
   *UNREADABLE*, in fact.  It takes me far longer to understand a bit of
   squeezed code then it does for me to understand well-braced and commented

   From my point of view, anyone who is working on a piece of code to
   improve it has a right to make adjustments to the syntax, within
   reason, to make it easier to understand and operate on the code.  If we
   try to impose one specific, set-in-stone way of doing things on the
   entire developer base we end up with lost interest and a lack of 
   evolution in the code.

   I can only repeat that when you try to apply a rule unconditionally,
   even to minor, unremarkable things, and let that govern your expectations
   in life, that the only result you will get is friction and a lessening of
   interest in the project.  It's like crying wolf over and over again.

   Save your arguments for the cases where it really matters and you might
   get better results.

   I'm going to leave you with one more comment.  I have been thanked on 
   many occassions by engineers and programmers working for all sorts of
   companies that delve into the FreeBSD kernel.  They have thanked me
   for providing clear comments and readable code that has allowed them 
   to come in blind and quickly ramp up their understanding of our kernel and
   their ability to modify it.  A lot of what I do I do not because *I*
   need it, personally, but because it helps the myrid engineers, sysops,
   and others who work with our system.  You may not appreciate it but
   plenty of others do and frankly I find that to be far more important
   then the occassional merge of otherwise unmaintained code between the 
   BSDs.  I've heard the 'easier to merge with other BSDs' argument many 
   times, but as far as I can tell the extra work involved pales in comparison
   to the time saved by all the third parties that use or work on the FreeBSD
   kernel.  Using the argument blindly as a justification to stop code
   evolution is just plain a dumb idea.

                                        Matthew Dillon 
                                        <[EMAIL PROTECTED]>

To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message

Reply via email to