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