On Fri, Nov 20, 2020 at 07:52:31AM +0100, Markus Armbruster wrote:
> Eduardo Habkost <ehabk...@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
