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

12 Mar 2025

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