Efficiency AND Readability

[Richard A. O'Keefe]

In article <8839 at smoke.BRL.MIL> gwyn at brl.arpa (Doug Gwyn (VLD/VMB) <gwyn>) writes:
>We should probably limit the code readability discussion to code
>as it is prepared for a standard compiler, not a version requiring
>preprocessing with some additional tool.

A discussion on code readability might well move to comp.lang.misc.
One would not want to ignore, for example, using SEDIT with INTERLISP.
Even a WEB-like tool can be extremely simple, if the language it is
meant for is straightforward.

If discussion is limited to what you can do for C in "ed", I would like
to suggest that a lot of the effort people put into putting huge
stereotyped headers in front of _functions_ is largely wasted:  the thing
which needs careful explanation in a lot of programs is the data
structures (and _NO_, C++ doesn't help: it simply provides more machinery
to help the coder make things obscure).  When you know what a data
structure is for, what invariants it is supposed to satisfy, and have a
couple of examples to look at (including debugging code for displaying
and validating them), it's ususally pretty easy to follow the code (if
the variable names are reasonable).