Eduardo Habkost <ehabk...@redhat.com> writes: > 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).
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!