Proposal for a scientific look at C style choices

[Geoff Clemm]

In article <9279 at ihlpb.ATT.COM> nevin1 at ihlpb.UUCP (55528-Liber,N.J.) writes:
>In article <272 at twwells.uucp> bill at twwells.UUCP (T. William Wells) writes:
>
>>I consider the braces as a separate element: sometimes necessary for
>>the compiler (but I always use the braces), but contributing little or
>>nothing to the understandability of the program.
>
>If the braces are necessary for the compiler (which they sometimes
>are), then they do contribute to the understandability of the program.
>Otherwise they wouldn't be necessary!

Apparently Bill didn't spell it out in enough detail ... this is the second
posting that uses the logic "if it's good for the compiler, it MUST be good
for a human", a non-sequitur at best (unless you still think coding in octal
is the way to go).

Humans process 2d information extremely well - they are only moderately good
at parsing long strings.  On the other hand, computers are very good at parsing
long strings - they are at best only moderately good at processing 2d 
information.  Indentation completely specifies the grouping.  If you see

xxxxx
   xxxxx
   xxxxxxx
xxxxx

and need this :

xxxxxx
   {
      xxxxxx
      xxxxxxxx
   }
xxxxx

to tell you that the second two lines are nested between the first and last,
your visual processing hardware is severely damaged.  On the other hand, the
computer lacks this processing hardware, and so the easiest thing is to provide
the bracket fluff to make its job easy.  To minimize the disruptive
influence on the human's 2d processing, bracket placement should minimize its
2d visual obtrusiveness.

> ... If the braces are wrong, my program
>probably won't do what I intended it to do.  If the indentation is
>wrong, my program can still compile and run correctly.  Indentation are
>like comments in that there is nothing to enforce them being correct.
>For maintaining other people's code, I can only rely on the same things
>that the compiler relies on (in this case, the braces instead of the
>indentation).

With the virtually universal availability of formatting tools (such as
indent, cb, etc, etc) and editors that auto-indent your code as you write
it (such as emacs), this argument has as much weight as arguing that
lines should have sequence numbers so that if you drop your card deck,
it is easy to get the statements back in order.

Geoff