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! /