Path: utzoo!attcan!uunet!husc6!cmcl2!rutgers!apple!bloom-beacon!bu-cs!purdue!decwrl!sgi!arisia!quintus!ok
From: ok@quintus.uucp (Richard A. O'Keefe)
Newsgroups: comp.lang.c
Subject: Re: Efficiency AND Readability
Message-ID: <662@quintus.UUCP>
Date: 11 Nov 88 04:57:10 GMT
References: <141@twwells.uucp> <3386@geaclib.UUCP> <8839@smoke.BRL.MIL>
Sender: news@quintus.UUCP
Reply-To: ok@quintus.UUCP (Richard A. O'Keefe)
Organization: Quintus Computer Systems, Inc.
Lines: 20

In article <8839@smoke.BRL.MIL> gwyn@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).