C99: Suggestions for style(9)

[Julian Elischer]

David Malone wrote:
> FWIW, I'd rarely support changing style(9), unless it is actually
> causing people to write bad code. It's designed to produce consistent
> code, and changing it does not encourage consistency.
> 
>>> -Do not put declarations
>>> -inside blocks unless the routine is unusually complicated.
>>> +Prefer declaring loop iterators in the for-statement to limit their scope.
> 
> I usually don't like this style - I like being able to review the
> variables used in a function at the top.

me too
though I've softenned a bit regarding puting variables in blocks,
I do NOT want to see variable declaration "not at the top of a block".

> 
>>> -When declaring variables in functions declare them sorted by size,
>>> -then in alphabetical order; multiple ones per line are okay.
>>> +When declaring variables in functions declare them sorted in alphabetical 
>>> order;
>>> +prefer one declaration per line, especially when pointer declarators or 
>>> +initializations are involved.
> 
> The change to prefer one declaration per line seems like an unnecessary,
> except to better accomodate the declare-at-initialisation below.

the 'size' bit used to be to save space.. all the chars
would be grouped together, etc.

> 
>>> +Prefer initializing variables right at their declaration.
> 

I have gone the other way on this.  Unless 'const' is being used I 
find I prefer to see them separately initialized.

> While I buy your argument about scope, as I said, I prefer to see
> everything declared at the top. I don't think it outweighs the
> advantage of being able to look through the declarations.
> 
>>> +When the value is not supposed to change in the function, make the 
>>> variable
>>> +const.
> 
> Using const seems sensible, and a good example of a time where
> declaring at initialisation makes sense.
> 
>>> +This makes it easier for a reader to identify the where the value of a 
>>> variable
>>> +originates.

yeah.. at the top of the function..

> 
> I'm not sure I buy this - the initialisation is unlikely to move in
> a piece of code, so it's as hard to find now as it was before. Editors
> supporting finding declarations should be able to find initialisations
> just as easily. (I'm old fashioned and do it via regexps.)
> 
> Note that I also compile code from time to time to versions of
> FreeBSD that don't support C99. I understand that this will get
> more difficult over time, but mixing declarations and code is one
> of the things that I trip over that are just an annoying unnecessary
> change. For me it makes my life more difficult for a small gain.
> 
>>> +Do not reuse the same variable in a different context, delare a new 
>>> variable.
> 
> I buy this largely - though it should be applied with common sense
> as usual.

hmm. I think an exception might be made for our old friends i,j,k

everyone knows them and what they are doing.. otherwise,yes this makes 
sense.

> 
>>> -Values in
>>> -.Ic return
>>> -statements should be enclosed in parentheses.
>>> -.Pp
> 
> This is another change that isn't worth making - style(9) has had
> this rule for years and changing it because you don't think it adds
> anything isn't a good reason.
> 

amen

>>> -Use ANSI function declarations unless you explicitly need K&R 
>>> compatibility.
>>> +Use ANSI function declarations.
> 

Everyone shuld be doing that already.
In new code, and in old code that they touch.

> Seems reasonable for modern code - I guess it might be worth noting
> that when converting from K&R to ANSI changes should be made with
> care to avoid the sort problems you mention.
> 
>> (It's a bug in GCC that it does not complain about the former.)
> 
> I thought gcc had some magic glue to make functions with ANSI
> declarations and K&R definitions work. Bruce would know the details.
> 
>> Empty line when there are no local variables:
>> Removed, because it does not improve readability and it actually hinders 
>> readability for very short functions, e.g. static inline functions, 
>> which just consist of one or two lines of code without any local 
>> variables except for parameters. Further, it makes even less sense with 
>> the changed recommendations for declarations.
> 
> FWIW, I buy the empty line rule as a matter of consistency. A better
> reason for getting rid of it (IMHO) would be that it is one of the
> rules that is not so well followed by our existing code base. On
> balance I'd leave this rule here, because I don't think the changes
> to decalarations are good and because changing for no good reason
> produces less consistent code in the long run.
> 
> (The example of very short static inline functions is probably a
> good one where no one would complain anyway if the code was missing
> the blank line. As always, style needs to be applied with good sense.)
> 
>> Last, but definitely not least, I added this paragraph about the use of 
>> local variables. This is to clarify, how today's compilers handle 
>> unaliased local variables. There is absolutely no need to reuse them in 
>> different contexts. Trying to optimise stack usage in this way is 
>> misguided and is a source of bugs, when a reused variable is not as dead 
>> as thought. For more reasons, please read the quoted diff.
>> Maxim, you requested this paragraph: Does this addition suit you?
> 
> This paragraph looks useful. If I were you I'd hook it in to the
> recommendation to not reuse the same variable in a different context.
> The only thing is that it reads a bit more like programming advice
> rather than style advice.
> 
> I'd also suggest you run any changes by Bruce.
> 
> 	David.
> _______________________________________________
> freebsd-hackers at freebsd.org mailing list
> http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
> To unsubscribe, send any mail to "freebsd-hackers-unsubscribe at freebsd.org"