From owner-freebsd-hackers@FreeBSD.ORG Fri May 1 14: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 45362106564A for ; Fri, 1 May 2009 14:40:07 +0000 (UTC) (envelope-from imp@bsdimp.com) Received: from harmony.bsdimp.com (bsdimp.com [199.45.160.85]) by mx1.freebsd.org (Postfix) with ESMTP id 8CD898FC1A for ; Fri, 1 May 2009 14:40:06 +0000 (UTC) (envelope-from imp@bsdimp.com) Received: from localhost (localhost [127.0.0.1]) by harmony.bsdimp.com (8.14.2/8.14.1) with ESMTP id n41Eb8kd042460; Fri, 1 May 2009 08:37:08 -0600 (MDT) (envelope-from imp@bsdimp.com) Date: Fri, 01 May 2009 08:37:12 -0600 (MDT) Message-Id: <20090501.083712.396385864.imp@bsdimp.com> To: christoph.mallon@gmx.de From: "M. Warner Losh" In-Reply-To: <20090501.081229.1359784281.imp@bsdimp.com> References: <20090430.183727.803597558.imp@bsdimp.com> <49FA8E88.1040905@gmx.de> <20090501.081229.1359784281.imp@bsdimp.com> X-Mailer: Mew version 5.2 on Emacs 21.3 / Mule 5.0 (SAKAKI) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Cc: rick-freebsd2008@kiwi-computer.com, freebsd-hackers@FreeBSD.org 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: Fri, 01 May 2009 14:40:07 -0000 In message: <20090501.081229.1359784281.imp@bsdimp.com> M. Warner Losh writes: : In message: <49FA8E88.1040905@gmx.de> : Christoph Mallon writes: : : M. Warner Losh schrieb: : : > In message: <20090430233648.GA95360@keira.kiwi-computer.com> : : > "Rick C. Petty" writes: : : > : On Thu, Apr 30, 2009 at 09:02:26AM -0600, M. Warner Losh wrote: : : > : > : : > : > This is the biggest one, and I think it may be too soon. Also, we : : > : > need to be careful on the initialization side of things because we : : > : > currently have a lot of code that looks like: : : > : > : : > : > : : > : > struct foo *fp; : : > : > struct bar *bp; : : > : > : : > : > fp = get_foo(); : : > : > if (!fp) return; : : > : > bp = fp->bp; : : > : > : : > : > this can't easily be translated to the more natural: : : > : > : : > : > struct foo *fp = get_foo(); : : > : > struct bar *bp = fp->bp; : : > : > : : > : > since really you'd want to write: : : > : > : : > : > struct foo *fp = get_foo(); : : > : > if (!fp) return; : : > : > struct bar *bp = fp->bp; : : > : > : : > : > which isn't legal in 'C'. : : > : : : > : I thought we were talking about C99, in which case this is perfectly legal. : : > : I certainly use it all the time in my C99 code. : : > : : > Hmmm, looks like that was added. That's ugly as C++... : : : : I do not think, this is ugly. On the contrary, it aids maintainability, : : because it reduces the scope of variables. Also quite some variables are : : only initialised and not changed afterwards, so it's nice to have the : : declaration and the only assignment in a single place. IMO this is a : : quite natural style, because you don't have anything in the code, before : : it is needed: Get the first pointer; if something is wrong, bail out; : : get the second pointer - the second pointer does not (textually) exist : : before it is needed. : : It is ugly. Hunting for declarations sucks, and it is one of the : things I really like about BSD code is that I don't have to. : : This is a religious point, and we're dangerously close to saying my : religion is better than your religion. I don't like this part of the : proposal at all. I can see the value in relaxing it for when you have : a series of variables that are initialized, but relaxing it to the : point where you intermix code and declarations goes way too far. It : is bad enough to have to deal with inner scopes, but tolerable. It is : intolerable to have to look for it anywhere in a big function. It : tends to encourage spaghetti code, which is one of the things that : style(9) tries to discourage in many subtle ways. This came off a little more absolute than I wanted. I should have added "in the absence of hard data..." Warner