From owner-freebsd-hackers@FreeBSD.ORG Sat May 2 17:08:35 2009 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id C2D031065674; Sat, 2 May 2009 17:08:35 +0000 (UTC) (envelope-from dwmalone@maths.tcd.ie) Received: from salmon.maths.tcd.ie (salmon.maths.tcd.ie [IPv6:2001:770:10:300::86e2:510b]) by mx1.freebsd.org (Postfix) with SMTP id 786558FC13; Sat, 2 May 2009 17:08:34 +0000 (UTC) (envelope-from dwmalone@maths.tcd.ie) Received: from walton.maths.tcd.ie ([134.226.81.10] helo=walton.maths.tcd.ie) by salmon.maths.tcd.ie with SMTP id ; 2 May 2009 18:08:32 +0100 (BST) Received: from localhost ([127.0.0.1] helo=maths.tcd.ie) by walton.maths.tcd.ie with SMTP id ; 2 May 2009 17:38:24 +0100 (BST) To: Christoph Mallon In-reply-to: Your message of "Sat, 02 May 2009 18:15:15 +0200." <49FC7193.40200@gmx.de> X-Request-Do: Date: Sat, 02 May 2009 17:38:24 +0100 From: David Malone Message-ID: <200905021738.aa71693@walton.maths.tcd.ie> Cc: FreeBSD Hackers , Roman Divacky , Ed Schouten , Warner Losh , Maxim Sobolev Subject: Re: C99: Suggestions for style(9) X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 02 May 2009 17:08:36 -0000 > > 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.