C99: Suggestions for style(9)

[Christoph Mallon]

David Malone schrieb:
>>> +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.
> 
> 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.)

But why not combine the benefits and find both at once in one place 
instead of of having an arbitrary amount of code between them? For 
example vim used "gd" to go to a local declaration.

> 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.

This is one thing, which I don't understand from the point of view of 
compiler construction: It is really simple to handle declarations, which 
are not at the beginning of a block. Other C99 features are way harder 
to implement. E.g. designator initialisers (bla bli = { .blub[23].gna = 
{ 42, "narf" } };) require *way* more effort. In the C99 standard 
initialisation covers 3 pages followed by another 3 pages of examples - 
which are quite some explanations and a *lot* of examples compared to 
the other parts of the standard.

>>> +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.

Of course, every rule has to be applied with common sense.

>>> -Use ANSI function declarations unless you explicitly need K&R 
>>> compatibility.
>>> +Use ANSI function declarations.
> 
> 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.

Removing the rule is in the first place about not adding any more 
old-style declarations. Removing the existing ones is a separate matter. 
rdivacky@ already did a good job at removing the defective declarations.

>> (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.

The standard explains in detail, what are compatible declarations. 
ISO/IEC 9899:1999 (E) §6.7.5.3:15 handles compatible function types. GCC 
plain violates this.

>> 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.

Why leave it as it is? Just remove it, so no more of these empty lines 
are added. There is no need to remove the existing ones at once. Just 
slowly get rid of them.

> (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.

It is rather long, so it should be kept separate.

> The only thing is that it reads a bit more like programming advice
> rather than style advice.

It has two sides: On the one side it is easier for a reader to 
understand the data flow. On the other side if aliasing comes into play 
(taking the address of a variable), then it is also beneficial from the 
point of view of code generation to keep different contexts separate.
My main concern is the reader of a piece of code. Better generated code 
is a nice side effect. It also shows that clarity for a reader and 
quality of the generated code nicely correlate here.

	Christoph