Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Path: utzoo!utgpu!water!watmath!clyde!cbosgd!ihnp4!ptsfa!lll-tis!mordor!sri-spam!rutgers!seismo!rochester!pt!cadre!pitt!amanue!jr
From: jr@amanue.UUCP
Newsgroups: comp.lang.c
Subject: Re: Writing readable code
Message-ID: <228@amanue.UUCP>
Date: Wed, 8-Jul-87 10:59:22 EDT
Article-I.D.: amanue.228
Posted: Wed Jul  8 10:59:22 1987
Date-Received: Sat, 11-Jul-87 16:39:25 EDT
References: <1158@copper.TEK.COM> <6858@auspyr.UUCP> <17171@cca.CCA.COM> <1221@ius2.cs.cmu.edu>
Organization: Amanuensis Inc., Grindstone, PA
Lines: 94
Summary: Putting function call outside the control structure is a problem

In article <1221@ius2.cs.cmu.edu>, edw@ius2.cs.cmu.edu (Eddie Wyatt) writes:
> In article <221@amanue.UUCP>, jr@amanue.UUCP (Jim Rosenberg) writes:
> > 	while ((c = getchar()) != EOF) {
> > 		.
> > 		.
> > 		.
> > 
> > ... But consider the alternative:
>                    ^^^^^^^^^^^^^^^
> > 
> > 	for (;;) {
> > 		c = getchar();
> > 		if (c == EOF)
> > 			break;
> > 		.
> > 		.
> > 		.
>    "the alternative"!  Come on there are a thousand and one ways to code
> the semantics of the above loop.  For example :
> 
> 
> 	c = getchar();
> 	while (c != EOF)
> 	    {
> 	    .
> 	    .
> 	    .
> 	    c = getchar();
> 	    }
> 


I don't mean to flame you, but as it happens I believe your solution is
dead wrong, on two counts.  (1) The two loops are *NOT EQUIVALENT*!  They
may be equivalent to Pascal programmers, but they certainly are not to C
programmers.  The reason is simply that in your version you must completely
forego the use of the continue statement.  The fact that break and continue
are missing from Pascal is a general class disaster, whereas the fact that
they're present in C is a constant joy.  A continue statement inside your
loop will obviously fail to reexecute getchar().  I suppose you could get
around that as follows:

	for (c = getchar(); c != EOF; c = getchar()) {
		.
		.
		.
	}

which frankly I don't find objectionable.

(2) Once again I must protest that your version is really less clear.  Think
about how *pseducode* for this loop might look:

	while (the next character is not EOF) {
		.
		. do stuff with that character
		.
	}

As I understand it the whole idea behind structured programming is to build
the logic insofar as possible by making boxes, where the control flow is
determined by what kind of box you have.  If we ignore (1) above your method
will work, but it doesn't really *EXPRESS THE THOUGHT* cogently.  It is not
c I'm really testing for EOF -- c is a handy tool that I use because I have
to have a variable name.  The real thought here is that it's "the next
character" that I'm testing for EOF.  By putting the call to getchar() right
there in while statement I state clearly that this is a "testing-the-next-
character" box -- which your code doesn't.

It's hard for me to fathom why the idea of assignment as an operator causes
such consternation.  It's obviously due to the fact that most progammers
learned some other language before they learned C (so did I for that matter)
and you get caught in a rut where it becomes hard to escape the habit that
assignment is a statement, and so must go on a line by itself.  Requiring
assingments to be on a line by themselves is no more necessary to code
clarity than adding dozens of useless temporary variables to arithmetic
expressions because you feel you should never be faced with the sight of
3 right parentheses in a row.

I will grant anybody that this is an aesthetic or philosophical argument,
and there are bound to be differing points of view.  Where I will get upset
is with those who believe that legitimate coding techniques like

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

are mere attempts to show off.  For *me* personally, putting the assignment
into the condition of the while statement is more clear and says what I mean
much more effectively than your version.  If you like call it a matter of
personal taste.
-- 
 Jim Rosenberg
     CIS: 71515,124                         decvax!idis! \
     WELL: jer                                   allegra! ---- pitt!amanue!jr
     BIX: jrosenberg                 seismo!cmcl2!cadre! /