From owner-freebsd-hackers@FreeBSD.ORG Sat May 2 17:40:07 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 936291065673 for ; Sat, 2 May 2009 17:40:07 +0000 (UTC) (envelope-from christoph.mallon@gmx.de) Received: from mail.gmx.net (mail.gmx.net [213.165.64.20]) by mx1.freebsd.org (Postfix) with SMTP id 131528FC15 for ; Sat, 2 May 2009 17:40:06 +0000 (UTC) (envelope-from christoph.mallon@gmx.de) Received: (qmail invoked by alias); 02 May 2009 17:40:05 -0000 Received: from p54A3DE1D.dip.t-dialin.net (EHLO tron.homeunix.org) [84.163.222.29] by mail.gmx.net (mp036) with SMTP; 02 May 2009 19:40:05 +0200 X-Authenticated: #1673122 X-Provags-ID: V01U2FsdGVkX1+xBstqmG+xEpHktQ6ORYM7K8DEkmdL68vJX4a4Qv EPdC/xp/B7xtZh Message-ID: <49FC8574.5060205@gmx.de> Date: Sat, 02 May 2009 19:40:04 +0200 From: Christoph Mallon User-Agent: Thunderbird 2.0.0.21 (X11/20090412) MIME-Version: 1.0 To: Julian Elischer References: <49F4070C.2000108@gmx.de> <20090502073658.GA65633@walton.maths.tcd.ie> <49FC752D.5080807@elischer.org> In-Reply-To: <49FC752D.5080807@elischer.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Y-GMX-Trusted: 0 X-FuHaFi: 0.53 Cc: Maxim Sobolev , FreeBSD Hackers , Roman Divacky , Ed Schouten , David Malone , Warner Losh 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:40:08 -0000 Julian Elischer schrieb: > David Malone wrote: >>>> -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". I find this kind of strange, because this in-beetwen makes least sense to me: Neither are all declarations grouped together nor are declarations nicely connected to their initialisation and their scope is minimal. >>>> -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. Today's compilers plain do not care in which order you declare variables. Sorting them in a beneficial way for space efficiency is better left to them (and it is a rather trivial thing to do). Also you cannot control if more spill slots have to be inserted or some values do not live in memory at all, so only the compiler can determine, which order is best. But a compiler can do more: It could coalesce the space of variables with disjoint life ranges. But this is much harder, because you have to properly determine the life ranges. Finding an arbitrary overestimation is easy, but the fun starts when looking at called functions, which get passed addresses of local variables. Also finding an optimal coalescence for known life ranges is NP-complete in the general case. But that's another story. (: >>>> +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. So you like hunting in multiple places instead of having both type and value conveniently in one place? >>>> +This makes it easier for a reader to identify the where the value >>>> of a variable >>>> +originates. > > yeah.. at the top of the function.. Currently only the *declaration* is at the top of the function. This bears absolutely no relation to where the *value* originates. >>>> +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 Especially they should be declared right where they are needed. C99 even conveniently allows the iterator variable to be declared in the first part of a for-loop: for (int i = 0; i != n; ++i) { ... }. By limiting their scope, this prevents accidently re-using stale values in a different place or other mistakes like the following: int i, j; for (i = 0;; ++i) { for (i = 0;; ++i) { /* oops, but compiler is happy */ } } for (j = 0;; ++j) { /* more */ } vs. for (int i = 0;; ++i) { for (int i = 0;; ++i) { /* warning about shadowed variable */ } } for (int j = 0;; ++j) { /* more */ } > 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 This is no church. I presented reasons, I do not want beliefs in return. Also stating that it should not be changed because it was always this way is a very slippery slope. >>>> -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. So, is this pro or contra removing the K&R-clause? Christoph