[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [PATCH v2 4/8] qnum: qnum_value_is_equal() function
From: |
Eduardo Habkost |
Subject: |
Re: [PATCH v2 4/8] qnum: qnum_value_is_equal() function |
Date: |
Fri, 20 Nov 2020 13:22:38 -0500 |
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).
>
> 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.
>
> 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. :)
(I'll still follow your advice as maintainer of that piece of
code, of course)
--
Eduardo
- Re: [PATCH v2 3/8] qnum: QNumValue type for QNum value literals, (continued)
[PATCH v2 4/8] qnum: qnum_value_is_equal() function, Eduardo Habkost, 2020/11/16
Re: [PATCH v2 4/8] qnum: qnum_value_is_equal() function, Markus Armbruster, 2020/11/19
[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