C99: Suggestions for style(9)

[David Malone]

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

As I said, I like having all the declarations in one place so I can
review all of them as a unit. I find it helps me understand the
function.  You can never have all the initialisations in one place,
because they may depend on complicated code, so I accept that I
have to search for initialisations.

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

True - but that's the compilers that I have to work with. I've
tripped over other C99 features considerably less often for some
reason.

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

Indeed!

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

As I said, the point of a style guide is consistency. Changing it
doesn't promote consistency, so there needs to be a good reason for
the change, rather than a good reason not to change. In my opinion,
there isn't a strong reason. Similarly for parens around return
values - there's nothing (substantial) wrong with either rule, so
they should probably be left as-is.

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

Maybe include a forward ref then, to say the rational is explained
in a later section?

	David.