Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Path: utzoo!mnetor!seismo!rochester!cornell!uw-beaver!mit-eddie!ll-xn!cit-vax!oberon!sdcrdcf!burdvax!bpa!cbmvax!vu-vlsi!cgh!amanue!jr
From: jr@amanue.UUCP (Jim Rosenberg)
Newsgroups: comp.lang.c
Subject: Re: Writing readable code
Message-ID: <221@amanue.UUCP>
Date: Tue, 30-Jun-87 23:09:21 EDT
Article-I.D.: amanue.221
Posted: Tue Jun 30 23:09:21 1987
Date-Received: Sat, 4-Jul-87 05:48:15 EDT
References: <1158@copper.TEK.COM> <6858@auspyr.UUCP> <17171@cca.CCA.COM> <13008@topaz.rutgers.edu>
Organization: Amanuensis Inc., Grindstone, PA
Lines: 63
Summary: while ((c = getchar()) != EOF) { makes it a different kind of loop

In article <13008@topaz.rutgers.edu>, ron@topaz.rutgers.edu (Ron Natalie)
writes:
>  [... other pet peeves ... ]
>
> 2.  Needless use of the comma operator and parenthesis to demonstrate
>     manhood to the obliteration of code readability, e.g.
> 
> 	    if((fd=open("foo",1)<0)
> 
>     SCREW this, too difficult, how about writing the code to indicate
>     what is going on:
> 
> 	    fd = open("foo", 1);
> 	    if(fd == -1)

I recall many moons ago whilst browsing K&R and before really learning C that I
swore up and down that I would forego such (what I thought at the time to be)
unwarranted over-abbreviation as:

	while ((c = getchar()) != EOF) {
		.
		.
		.

It didn't take me long once I was actually using C on a regular basis to
realize that forgoing constructs such as the one above is not only ridiculous,
a case can be made that it is actually LESS CLEAR stylistically.  Yes, it is
more difficult to read for novices to C.  But consider the alternative:

	for (;;) {
		c = getchar();
		if (c == EOF)
			break;
		.
		.
		.

I would argue that a strong case can be made that the for loop is actually
LESS CLEAR than the while loop.  By announcing the for loop as a forever loop,
in effect I'm saying that I really don't know what will terminate this loop
'till I find it.  But of course I *do* know, as the while loop shows.  I.e.
the while loop is more clear because it does a better job of "front-loading"
the code so the reader can understand what's coming.  A true forever loop is a
whole different kettle of fish than a loop where you really can predict in
advance the condition that will cause it to terminate.  It seems to me to be a
self-evident principle of coding clarity that the sooner in the code you can
state your intentions the better, other things being equal.  If you forego
using *ANY* assignments in expressions then you must use the forever loop to
code this example, which logically speaking isn't really right.

Using assignments in expressions can be taken to extremes of course, but it
doesn't always hide what's going on -- sometimes it *REVEALS* what is going
on.  Note that I'm making this point purely on the basis of code readability,
regardless of what number of machine cycles the generated code might save.
The case you made was for if statements not loops, but once you get used to
the idea, judicious use of an assignment in an expression will seem perfectly
natural.  I think it certainly does to 90% of all C programmers, and it's not
a matter of showing off.  It's a matter of saying what you mean.
-- 
 Jim Rosenberg
     CIS: 71515,124                         decvax!idis! \
     WELL: jer                                   allegra! ---- pitt!amanue!jr
     BIX: jrosenberg                 seismo!cmcl2!cadre! /