Re: coding style, continuing education

[Nix <nix at esperi dot demon dot co dot uk>]

On Fri, 19 Jan 2001, Phil Edwards spake:
> Chapter 4 starts off:
> 
> #   Functions should be short and sweet, and do just one thing.  They should
> #   fit on one or two screenfuls of text (the ISO/ANSI screen size is 80x24,
> #   as we all know), and do one thing and do that well.
> 
> The 60-line 'if' expressions pretty much blew that test.

The problem with *that* suggestion is that, for some of those
expressions, the only way to re-express them is either to produce a
bunch of one-off macros (which is quite ugly) or to cut the if statement
into a ladder of ifs (which is simply pointless).

I think that particular suggestion is all well and good for a kernel ---
which, after all, hasn't got *that* many desperately complicated
decisions to make (many of its decisions being made for it, at compile
time) --- but may not be so useful for a compiler, the whole raison d'etre
of which is to indulge in desperately complicated decisions...

I don't think hugely long conditional expressions should be common, by
any means, but I don't think that if they occur and can't be decomposed
easily[1], the code should be distorted to fit this sort of rule.

So we need a way to format them nicely. Might I throw out the
possibility of something like

    <code>

    /* Verify if we need to... */

        /* We need to if... */
    if (((...)
        && (...)
        && ((...)
           || (...)))
        /* ... or if... */
        || (...)

i.e. indent the comments within the conditional expression to the
nesting level of the operators that precede the brackets in that part of
the nesting.

(Maybe it looks too ugly. I'm not sure. Certainly it makes the
distinction between the block comment and the smaller comments above
conditional pieces more concrete.)


btw, I just noticed; at least *some* long conditionals, like the one I
pointed at in combine, are already using this style; at least the
indentation of the comments part. The combine conditional simply
mis-indents the topmost comment and doesn't have a description of the
entire conditional.

The GNU coding standards don't seem to comment on this.

> Of course, this is also the file that starts off by recommending that the
> prospective coder print out a copy of the GNU coding standards and burn
> them as a symbolic gesture.  :-)  Which I must admit I've been tempted to
> do on many occasions, but that's not germane to the discussion...

Oddly, I found that in ~87--90 I independently evolved a coding style
that's almost exactly like the GNU coding standards. I'd never heard of
GNU (or even free software) at the time, and had never seen any GNU
source; perhaps this was morphic resonance ;)

Seeing GNU-style source, in the morass of K&R-style indentation and
Whitesmiths indentation out there is like coming home...


[1] i.e. separating out generic and generally useful tests into macros,
    rather than separating out specialized ones just to cut the
    conditional size down (not that we'd do that; but I've seen it done
    in other code, and it's not nice.)

-- 
`Anyhow, that pipe dream doesn't say anything about the question you
 asked.  (I am planning for a career in politics.)' --- Mark Mitchell
                                                      on the GCC list