Date: Sat, 02 May 2009 17:38:24 +0100 From: David Malone <dwmalone@maths.tcd.ie> To: Christoph Mallon <christoph.mallon@gmx.de> Cc: FreeBSD Hackers <freebsd-hackers@freebsd.org>, Roman Divacky <rdivacky@freebsd.org>, Ed Schouten <ed@freebsd.org>, Warner Losh <imp@freebsd.org>, Maxim Sobolev <sobomax@freebsd.org> Subject: Re: C99: Suggestions for style(9) Message-ID: <200905021738.aa71693@walton.maths.tcd.ie> In-Reply-To: Your message of "Sat, 02 May 2009 18:15:15 %2B0200." <49FC7193.40200@gmx.de>
next in thread | previous in thread | raw e-mail | index | archive | help
> > 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.
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?200905021738.aa71693>