Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Posting-Version: version B 2.10 5/3/83; site cubsvax.UUCP
Path: utzoo!watmath!clyde!floyd!cmcl2!rocky2!cubsvax!peters
From: peters@cubsvax.UUCP
Newsgroups: net.lang
Subject: Re: Forced Commenting - (nf) - and commenting in general
Message-ID: <170@cubsvax.UUCP>
Date: Mon, 20-Feb-84 09:30:03 EST
Article-I.D.: cubsvax.170
Posted: Mon Feb 20 09:30:03 1984
Date-Received: Wed, 22-Feb-84 01:29:48 EST
References: <117@iuvax.UUCP>, <1706@randvax.ARPA>
Organization: Columbia Univ Biology, New York City
Lines: 21

I used to code in APL, whose conciseness has two implications, one 
"good" and one "bad:"  On the good side, since a procedure that would take
ten lines in C would take a single line in APL, it was very rare that a
procedure was more than a screen (24 lines) long, and most were 5 -10 lines.
This made it very easy to look at a whole procedure at once and figure out
what it was doing -- hence tending to make prolific commenting less 
necessary.  On the other hand, there was so much in a single line that
it was sometimes hard to see what was being done on a very detailed level,
which tended to make comments *more* necessary.  In most languages the
thing to be concerned about is "missing the forest for the trees."  In
APL, I used to worry more about "missing the trees for the forest."

I usually had a few block 
comment lines at the beginning of a procedure, and more only when necessary, 
or when the procedure was very long.  Then I had a routine which would
go through a workspace and print only function headers and comment lines.
Printing these out for all the routines in a workspace gave a wonderful 
synoptic view of what the different functions did.

{philabs,cmcl2!rocky2}!cubsvax!peters            Peter S. Shenkin 
Dept of Biol. Sci.;  Columbia Univ.;  New York, N. Y.  10027;  212-280-5517