From owner-svn-src-head@FreeBSD.ORG Sun Mar 22 13:33:43 2009 Return-Path: Delivered-To: svn-src-head@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id AB58E1065673 for ; Sun, 22 Mar 2009 13:33:43 +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 1524D8FC1C for ; Sun, 22 Mar 2009 13:33:42 +0000 (UTC) (envelope-from christoph.mallon@gmx.de) Received: (qmail invoked by alias); 22 Mar 2009 13:33:41 -0000 Received: from p54A3FD39.dip.t-dialin.net (EHLO tron.homeunix.org) [84.163.253.57] by mail.gmx.net (mp036) with SMTP; 22 Mar 2009 14:33:41 +0100 X-Authenticated: #1673122 X-Provags-ID: V01U2FsdGVkX1++hawlWA++RbcH54C+Jy2jZjHwZx9+N28Fs2BZ8J DzHd4X//wSD4gZ Message-ID: <49C63E34.4030303@gmx.de> Date: Sun, 22 Mar 2009 14:33:40 +0100 From: Christoph Mallon User-Agent: Thunderbird 2.0.0.19 (X11/20090103) MIME-Version: 1.0 To: "M. Warner Losh" References: <49C5737F.1050902@gmx.de> <20090321.175756.-434257642.imp@bsdimp.com> <49C5F88C.3070600@freebsd.org> <20090322.070349.195750067.imp@bsdimp.com> In-Reply-To: <20090322.070349.195750067.imp@bsdimp.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Y-GMX-Trusted: 0 X-FuHaFi: 0.5600000000000001 Cc: svn-src-head@FreeBSD.org, svn-src-all@FreeBSD.org, src-committers@FreeBSD.org, avg@FreeBSD.org, marius@alchemy.franken.de Subject: Re: svn commit: r190098 - in head/sys/sparc64: fhc sparc64 X-BeenThere: svn-src-head@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: SVN commit messages for the src tree for head/-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 22 Mar 2009 13:33:44 -0000 M. Warner Losh schrieb: > In message: <49C5F88C.3070600@freebsd.org> > Andriy Gapon writes: > : on 22/03/2009 01:57 M. Warner Losh said the following: > : > I'll point out that style(9) doesn't say use as few local variables as > : > possible... That part is completely unspecified. > : > : But it does say: > : Do not put declarations inside blocks unless the routine is unusually > : complicated. > > Yea, so? Just put them at the top of the function where they belong > and don't worry about it. Christoph has a long reason why this isn't bad. Maybe I misunderstand your sentence here, but I'm *against putting all declarations at the top* of the function and I'm *for declaring and initialising* variables right where you need them. > : "unusually complicated" is, of course, a very subjective measure. > : But still this guideline contradicts typical guidelines for C and its > : offspring which name we do not say to declare variables as close to > : their first usage as possible. > > thousands of lines is unusually complicated. So every function of FreeBSD's kernel is trivial? Or is "ordinary complicated" not a reason enough for better readability? > : E.g. you can have a simple 3 line block where you need a local variable > : but that block is located 50 lines from start of an enclosing function. > : Very convenient when you need to quickly glance the variable's type (not). > > No you don't. There's absolutely nothing wrong with putting them at > the top. In fact, it is simpler, really, than having to go hunting > for dozens of different declarations. As someone who has spent a lot > of time looking at code, the time wasted looking for these damn-fool > things really adds up. I fully disagree. I prefer seeing the declaration right where the assignment/initialisation is instead of hunting for it two pages up. Also for the rare case that you cannot directly spot the declartaion a few lines up, every editor/IDE I know, which is more advanced than ed, has a "jump to declaration" key combination and I prefer when it just moves a few lines up instead of two pages and puts me totally somewhere else. E.g. for vim the key combination is "gd". Others (e.g. Eclipse) highlight the declaration when you move the cursor over a use of the variable and if it is two pages up you do not see the highlight. > The original point is valid: the code changes obfuscated perfectly > readable code for no gain in the object code. I agree here, but probably for mostly different reasons. Christoph