All of lore.kernel.org
 help / color / mirror / Atom feed
From: Anthony Liguori <anthony@codemonkey.ws>
To: Aurelien Jarno <aurelien@aurel32.net>
Cc: Blue Swirl <blauwirbel@gmail.com>, qemu-devel@nongnu.org
Subject: Re: [Qemu-devel] [PATCH] Drop braces around single statement rule
Date: Mon, 02 Aug 2010 10:20:51 -0500	[thread overview]
Message-ID: <4C56E253.7010403@codemonkey.ws> (raw)
In-Reply-To: <20100731234956.GJ31640@hall.aurel32.net>

On 07/31/2010 06:49 PM, Aurelien Jarno wrote:
> On Sat, Jul 31, 2010 at 08:23:55PM +0000, Blue Swirl wrote:
>    
>> On Sat, Jul 31, 2010 at 4:23 PM, malc<av1474@comtv.ru>  wrote:
>>      
>>> History has shown that this particular rule is unenforcable.
>>>
>>> Signed-off-by: malc<av1474@comtv.ru>
>>> ---
>>>   CODING_STYLE |   11 ++++++-----
>>>   1 files changed, 6 insertions(+), 5 deletions(-)
>>>        
>> Not again:
>> http://lists.nongnu.org/archive/html/qemu-devel/2009-12/msg00484.html
>>
>> There are plenty of ways to make the rule enforceable, for example we
>> could agree to start to revert commits which introduce new
>> CODING_STYLE violations.
>>
>>      
> It seems to be possible to add a pre-applypatch script to the git hook
> directory, that will verify the commit and reject it if it doesn't
> comply with the coding rules. Of course it's possible to commit a patch
> anyway by using --no-verify.
>    

There are certain aspects of CODING_STYLE that I think are pretty 
important.  For instance, space vs. tabs can really screw things up for 
people that have non-standard tabs.  This is something that enforcing at 
patch submission time seems to be really important.

Type naming seems important too because it's often not isolated.  IOW, a 
poor choice in one file can end up polluting other files quickly that 
require interacting.  The result is a mess of naming styles.

But something like braces around an if doesn't seem like it creates a 
big problem.  Most C programmers are used to seeing braces in some 
statements and not other.  Therefore, it's hard to argue that the code 
gets really unreadable if this isn't strictly enforced.

So really, I think the problem is that we're enforcing the words of 
CODING_STYLE instead of the intent.  The intent of CODING_STYLE is to 
improve the readability of the code.  I think it requires a certain 
amount of taste to be applied.

Rejecting a big patch because braces aren't used in single line if 
statements seems to be an unnecessary barrier to me.

Regards,

Anthony Liguori

> The good point of this approach is that the rule is enforced by a
> script, which is not suppose to make mistakes, and that it can be shared
> between patch submitters and patch committers: both side can make
> mistakes and it is always better to know that as early as possible.
>
> Of course someone as to translate the coding rules in a set of regular
> expressions able to catch errors.
>
>    

  reply	other threads:[~2010-08-02 15:21 UTC|newest]

Thread overview: 16+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2010-07-31 16:23 [Qemu-devel] [PATCH] Drop braces around single statement rule malc
2010-07-31 16:47 ` Aurelien Jarno
2010-07-31 16:51   ` Aurelien Jarno
2010-07-31 20:23 ` Blue Swirl
2010-07-31 20:35   ` malc
2010-07-31 23:49   ` Aurelien Jarno
2010-08-02 15:20     ` Anthony Liguori [this message]
2010-08-02 15:41       ` Kevin Wolf
2010-08-02 15:48         ` Anthony Liguori
2010-08-02 16:06           ` malc
2010-08-02 16:18             ` Anthony Liguori
2010-08-02 16:29               ` Blue Swirl
2010-08-02 16:32                 ` Anthony Liguori
2010-08-02 15:55         ` malc
2010-08-02 16:04           ` Anthony Liguori
2010-08-02 16:24       ` Blue Swirl

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=4C56E253.7010403@codemonkey.ws \
    --to=anthony@codemonkey.ws \
    --cc=aurelien@aurel32.net \
    --cc=blauwirbel@gmail.com \
    --cc=qemu-devel@nongnu.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.