[COFF] [TUHS] What would early alternatives to C have been?

[Douglas McIlroy]

Beating a nearly dead horse, I'm shipping this to COFF instead of TUHS
to which it responds.

>  I find
>
>       if (a == b && c == d)
>
> perfectly reasonable, but
>
>       if ((a == b) && (c == d))
>
> to be just silly.

Amusing. IT's odd that no one has mentioned the use of spaces for
grouping.  When the operands of == are simple, I prefer to vary the
spacingy spacing. It's less intrusive than extra parentheses and just
as clear.

        if(a==b && c==d) or
        if( a==b && c==d )

K&R usually flank every infix operator with spaces, unlike classical
mathematical usage, where spacing reflects operator precedence. I
usually write a*b + c*d, not a * b + c * d, which wantonly flattens
the parse tree. Here's an example from K&R, where uniform spacing
hampers intelligibility.

        for (i = 0; s[i] >= '0' && s[i] <= '9'; ++i)
                n = 10 * n + (s[i] - '0');

The "extra" parens in the second line admirably show the intent of the
subtraction. Other groupings are not so well indicated. I would write
it like this:

        for(i=0; s[i]>='0' && s[i]<='9'; ++i)
                 n = 10*n + (s[i]-'0');

(I'll admit that the juxtaposition ]>= is less than perspicuous.)

Long identifiers constitute a level of grouping that takes precedence
even over multiplication. So I may flank long identifiers with spaces.
I suppose then + in a sum of  products might deserve double spaces.
That's probably a bridge too far, but double spaces after the
semicolons in the "for" statement above seem justifiable

K&R aren't absolutely rigid about spacing. In the following oddly
mixed specimen, the first of three operands in a conjunction is spaced
tightly, but the third is not; I guess they feel about != the way I do
about long identifiers.

        i<lim-1 && (c = getchar()) != '\n' && c != EOF

The middle conjunct is a challenge. I'd probably squeeze out the
spaces. But I might instead try to hold it together with outer parens.

Doug