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.
>
>
next prev parent 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.