[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!
[PATCH v2 7/8] qom: Make object_property_set_default() public, Eduardo Habkost, 2020/11/16
[PATCH v2 8/8] qom: Use qlit to represent property defaults, Eduardo Habkost, 2020/11/16
[PATCH v2 6/8] qlit: qlit_type() function, Eduardo Habkost, 2020/11/16
[PATCH v2 5/8] qlit: Support all types of QNums, Eduardo Habkost, 2020/11/16