From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from [140.186.70.92] (port=47607 helo=eggs.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1OfxtN-0005GK-GT for qemu-devel@nongnu.org; Mon, 02 Aug 2010 12:29:35 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.69) (envelope-from ) id 1OfxtJ-0006TA-13 for qemu-devel@nongnu.org; Mon, 02 Aug 2010 12:29:31 -0400 Received: from mail-qy0-f173.google.com ([209.85.216.173]:56684) by eggs.gnu.org with esmtp (Exim 4.69) (envelope-from ) id 1OfxtI-0006T2-TB for qemu-devel@nongnu.org; Mon, 02 Aug 2010 12:29:28 -0400 Received: by qyk35 with SMTP id 35so5414167qyk.4 for ; Mon, 02 Aug 2010 09:29:28 -0700 (PDT) MIME-Version: 1.0 In-Reply-To: <4C56EFD2.9010908@codemonkey.ws> References: <1280593414-2232-1-git-send-email-av1474@comtv.ru> <20100731234956.GJ31640@hall.aurel32.net> <4C56E253.7010403@codemonkey.ws> <4C56E732.7060102@redhat.com> <4C56E8CB.1090104@codemonkey.ws> <4C56EFD2.9010908@codemonkey.ws> From: Blue Swirl Date: Mon, 2 Aug 2010 16:29:08 +0000 Message-ID: Subject: Re: [Qemu-devel] [PATCH] Drop braces around single statement rule Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable List-Id: qemu-devel.nongnu.org List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Anthony Liguori Cc: Kevin Wolf , qemu-devel@nongnu.org, Aurelien Jarno On Mon, Aug 2, 2010 at 4:18 PM, Anthony Liguori wro= te: > On 08/02/2010 11:06 AM, malc wrote: >> >> On Mon, 2 Aug 2010, Anthony Liguori wrote: >> >> >>> >>> On 08/02/2010 10:41 AM, Kevin Wolf wrote: >>> >>>> >>>> >>>>> >>>>> But something like braces around an if doesn't seem like it creates a >>>>> big problem. =C2=A0Most C programmers are used to seeing braces in so= me >>>>> statements and not other. =C2=A0Therefore, it's hard to argue that th= e code >>>>> gets really unreadable if this isn't strictly enforced. >>>>> >>>>> >>>> >>>> I won't argue that missing braces impact readability of the code, they >>>> probably don't. However, as was pointed out in earlier discussion ther= e >>>> still remain two important points: >>>> >>>> 1. While it doesn't make a difference for the code itself, readability >>>> of patches suffers when braces have to be added/removed when a second >>>> line is inserted or disappears. >>>> >>>> >>> >>> I understand the argument but it's not something that I strongly agree >>> with. >>> >>> >>>> >>>> 2. I've messed up more than once with adding some debug code (even wor= se >>>> when it happens with real code): >>>> >>>> if (foo) >>>> =C2=A0 =C2=A0 =C2=A0 fprintf(stderr, "debug msg\n"); >>>> =C2=A0 =C2=A0 =C2=A0 bar(); /* oops, not conditional any more */ >>>> >>>> >>> >>> This is hard to do with editors that auto indent unless you're copying >>> and >>> pasting debugging. =C2=A0And yeah, I've made that mistake too doing the= later >>> :-) >>> >>> >>>> >>>> This is why I tend to disagree with removing the rule, and suggest to >>>> rather implement some automatic checks like Aurelien suggested (if we >>>> need to change anything at all). I usually don't ask for a respin just >>>> for braces if the patch is good otherwise, but if you think we should >>>> just reject such patches without exceptions, I can change that. >>>> >>>> >>> >>> Yeah, I try to remember to enforce it but often forget or just don't >>> notice. >>> My eyes don't tend to catch missing braces like they would catch bad ty= pe >>> naming because the former is really not uncommon. >>> >>> I'm happy with the status quo but I won't object to a git commit hook >>> that >>> enforces style. >>> >> >> Seriously? You are happy with the situation where some people get their >> patches rejected because they disagree/forogot/don't_care about single >> statement braces while the patches of others make it through? >> > > Yeah, I'm neglecting the fact that we're not consistent as maintainers an= d > I'm all for dropping it from CODING_STYLE. I'd rather expand the document. For example, I like the approach libvirt ta= kes: http://libvirt.org/git/?p=3Dlibvirt.git;a=3Dblob_plain;f=3DHACKING;hb=3DHEA= D Not specifically to braces, but they describe types and memory allocation etc. which is FAQ stuff for us too.