qemu-ppc
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Qemu-ppc] [Qemu-devel] [PATCH 07/10] pseries: Clean up error handli


From: Alexey Kardashevskiy
Subject: Re: [Qemu-ppc] [Qemu-devel] [PATCH 07/10] pseries: Clean up error handling in spapr_rtas_register()
Date: Wed, 20 Jan 2016 19:15:26 +1100
User-agent: Mozilla/5.0 (X11; Linux i686 on x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.5.0

On 01/20/2016 06:18 PM, Markus Armbruster wrote:
Eric Blake <address@hidden> writes:

On 01/19/2016 05:21 PM, Alexey Kardashevskiy wrote:

You could drop the redundant () while touching this, as in:


Seriously? Why? I personally find it really annoying (but I stay silent)
when people omit braces in cases like this.


assert(token >= RTAS_TOKEN_BASE && token < RTAS_TOKEN_MAX);

Because it's the prevailing style. I estimate that less than 10% of qemu
over-parenthesizes, mostly because && and || are well-known C operator
precedence:

$ git grep ' && ' | wc
    6462   57034  482477
$ git grep ') && (' | wc
     578    6151   48655

Of course, that's a rough estimate, as it has false positives on 'if
(foo() && (b || c))', and false negatives on conditionals where there is
a unary rather than binary operator on either side of &&; but I'm sure
you could write a Coccinelle script if you wanted more accurate counting.

But you are equally right that as long as HACKING doesn't document it,
and checkpatch.pl doesn't flag it, then you can over-parenthesize binary
arguments to the short-circuiting operators to your aesthetic tastes.

HACKING doesn't document everything.  Trying to document everything
would drown the interesting parts in a sea of platitudes, and still
leave innumerable loopholes.

checkpatch.pl doesn't flag everything.  It checks for *common* unwanted
patterns.

When HACKING and checkpatch.pl are silent, make your change blend in
with the existing code.  Since the existing code overwhelmingly eschews
this kind of superfluous parenthesis, the general rule is to knock them
off unless *local* code overwhelmingly uses them.


In order to educate myself - where/when was this wonderful rule established? What are the other rules then?


Just because HACKING doesn't explicitly prohibit your personal
preferences doesn't mean you get to do leave your stylistic mark on the
code.  Show some taste and make yourself invisible.

Nice, now we are discussing taste :-/


--
Alexey



reply via email to

[Prev in Thread] Current Thread [Next in Thread]