qemu-devel
[Top][All Lists]
Advanced

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

Re: [PATCH v2 4/8] qnum: qnum_value_is_equal() function


From: Markus Armbruster
Subject: Re: [PATCH v2 4/8] qnum: qnum_value_is_equal() function
Date: Mon, 23 Nov 2020 09:17:59 +0100
User-agent: Gnus/5.13 (Gnus v5.13) Emacs/27.1 (gnu/linux)

Eduardo Habkost <ehabkost@redhat.com> writes:

> On Fri, Nov 20, 2020 at 07:52:31AM +0100, Markus Armbruster wrote:
>> Eduardo Habkost <ehabkost@redhat.com> writes:
>> 
>> > On Thu, Nov 19, 2020 at 11:27:40AM +0100, Markus Armbruster wrote:
>> > [...]
>> >> > +bool qnum_is_equal(const QObject *x, const QObject *y)
>> >> > +{
>> >> > +    const QNum *qnum_x = qobject_to(QNum, x);
>> >> > +    const QNum *qnum_y = qobject_to(QNum, y);
>> >> 
>> >> Humor me: blank line between declarations and statements, please.
>> >
>> > I can do it.  But why do you prefer it that way?
>> 
>> Habit borne out of C lacking other visual cues to distinguish
>> declarations and statements.
>
> Why is the distinction important, when many variable declarations
> also include initializer expressions that can be as complex as
> other statements?
>
> (The qobject_to() calls above are an example).

We read left to right, and we're not good at backtracking.  The earlier
I know I'm reading a declaration, the better.

>> Declaration or statement?  Tell me quick, don't analyze!
>> 
>>     mumble(*mutter)();
>> 
>> This "obviously" declares @mutter as pointer to function returning
>> mumble.
>> 
>> Except when @mumble isn't a typedef name, but a function taking one
>> argument and returning a function that takes no argument.  Then it
>> passes *mutter to mumble(), and calls its return value.
>> 
>> The whole point of coding style is to help readers along.  Two stylistic
>> conventions that can help here:
>> 
>> 1. In a function call, no space between the expression denoting the
>>    called function and the (parenthesized) argument list.  Elsewhere,
>>    space.
>> 
>>    So, when the example above is indeed a declaration, write it as
>> 
>>         mumble (*mutter)();
>> 
>>    If it's function calls, write it as
>> 
>>         mumble(*mutter)();
>
> This makes lots of sense.  Starting with a word followed by space
> is what makes declarations visually distinguishable.

Declarations need not match that pattern.  Also, it's a rather subtle
cue.

>> 2. Separate declarations from statements with a blank line.  Do not mix
>>    them.
>
> I'm not sure about this one, and I'm actually glad it is not part
> of CODING_STYLE.  :)

That's why I ask to "humor me" :)

For what it's worth, the convention is common enough to be supported by
the traditional BSD indent program.

> (I'll still follow your advice as maintainer of that piece of
> code, of course)

Thanks!




reply via email to

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