robert@cs.arizona.edu (Robert J. Drabek) (03/25/90)
In article <340018@hplvli.HP.COM>, boyne@hplvli.HP.COM (Art Boyne) writes: > jgk@osc.COM (Joe Keane) writes: > >Here's my biggest C style peeve. For some reason, many C programmers insist > >on always putting parentheses around return values, even when they're not > > Also, 'while', 'for', 'if', etc., > all *require* parenthesis, so it's a reasonable habit to acquire. But as Joe Keane said, these constructs require the parenthesis for a particular reason and few people understand that reason. Also, Joe Keane made the point that many people put parenthesis in simply because they see other people do it. And there are those who believe return is a function and hence required! I require my students to use the absolute minimum number of parenthesis until they have ALL the rules down pat. After leaving my courses (or in the privacy of their own PC) they'll do whatever feels good, but I will have done my job as well as I can by getting them to understand these details. Please, I know parenthesis are sometimes an aid in producing readable code and they are also clutter which can make for less-readable code. -- Robert J. Drabek robert@cs.Arizona.EDU Department of Computer Science uunet!arizona!robert The University of Arizona 602 621 4326 Tucson, AZ 85721
dbuksba@ic.sunysb.edu (Peter B. Henderson) (03/26/90)
In article <19356@megaron.cs.arizona.edu> robert@cs.arizona.edu (Robert J. Drabek) writes: >In article <340018@hplvli.HP.COM>, boyne@hplvli.HP.COM (Art Boyne) writes: >> jgk@osc.COM (Joe Keane) writes: >> >Here's my biggest C style peeve. For some reason, many C programmers insist >> >on always putting parentheses around return values, even when they're not >> >> Also, 'while', 'for', 'if', etc., >> all *require* parenthesis, so it's a reasonable habit to acquire. > >But as Joe Keane said, these constructs require the parenthesis for a >particular reason and few people understand that reason. > >Also, Joe Keane made the point that many people put parenthesis in >simply because they see other people do it. And there are those who >believe return is a function and hence required! > >I require my students to use the absolute minimum number of parenthesis >until they have ALL the rules down pat. After leaving my courses (or in >the privacy of their own PC) they'll do whatever feels good, but I will >have done my job as well as I can by getting them to understand these >details. > >Please, I know parenthesis are sometimes an aid in producing readable >code and they are also clutter which can make for less-readable code. >-- >Robert J. Drabek robert@cs.Arizona.EDU >Department of Computer Science uunet!arizona!robert >The University of Arizona 602 621 4326 >Tucson, AZ 85721 Being a student as well as a software developer, I have found it necessary to develop a standard way of coding, or a routine that I force myself to follow. I learned C by myself out of a collection of now outdated books, and have seen the return statement used in both ways. I personally use: return (2+2); The reason for this is due to the nature of C. I could create, and have, a return statement that runs off the page due to the way the return value is being acquired. I have found that by putting parenthesis around the statement I have made it mor readable for me. Being also fluent in Lisp, I understand the disadvantage of parenthesis, but nevertheless it should be used in order to maintain consistency with the programmers style. As to the students lack of understanding concerning the parenthesis, this is due to their not reading the text book, or listening to the lecture carefully, but not to their use of parenthesis. I have seen many a C text book, but never have I seen one that did not explain what difference between a function and a statement is, and that return was a statement. -Of course this is just one mans opinion. David T. Buksbaum -- +---------------------------------------------------------+ = David T. Buksbaum * *** NOTICE *** = = HAND 225A * = = Stony Brook, Ny * UNDER CONSTRUCTION =
hascall@cs.iastate.edu (John Hascall) (03/26/90)
robert@cs.arizona.edu (Robert J. Drabek) writes: }I require my students to use the absolute minimum number of parenthesis }until they have ALL the rules down pat. Operator precedence and associativity in C is quite complicated and somewhat non-intuitive. A few well-placed parentheses can go a long way toward promoting readability and understanding, even if they are not strictly necessary.[1] This mess has "the absolute minimum number of parentheses": a /= b ? c << 3 & g || f ? e || 2 + ++d & ~c : w : z; }Please, I know parenthesis are sometimes an aid in producing readable }code and they are also clutter which can make for less-readable code. Extra parenthesization, even full parenthesization need not be mutually exclusive with readability, that's what whitespace is for! a /= (b ? ( (((c << 3) & g) || f) ? ( (e || ((2 + ++d) & ~c)) : w ) : z ) ); But then, I'm not much for dogma, John Hascall (that's pronounced "throat warbler mangrove" :-) hascall@atanasoff.cs.iastate.edu ---------- [1] "Parentheses are not necessary around the first expression of a conditional expression, since the precedence of ?: is very low, just above assignment. They are advisable anyway, however, since they make the conditional part of the expression easier to see." (K&R1 p. 48)
karl@haddock.ima.isc.com (Karl Heuer) (03/26/90)
In article <19356@megaron.cs.arizona.edu> robert@cs.arizona.edu (Robert J. Drabek) writes: >In article <340018@hplvli.HP.COM>, boyne@hplvli.HP.COM (Art Boyne) writes: >>Also, 'while', 'for', 'if', etc., all *require* parenthesis... > >But as Joe Keane said, these constructs require the parenthesis for a >particular reason and few people understand that reason. There's one exception: in the do-while statement, the language definition requires the parentheses even though there would be no syntactic difficulty without them. (The semicolon would suffice to terminate the expression, just as it does with return.) Karl W. Z. Heuer (karl@ima.ima.isc.com or harvard!ima!karl), The Walking Lint)
scs@athena.mit.edu (Steve Summit) (03/26/90)
I stopped using parentheses after "return" because I happen to mistype that particular keyword a lot, and retunr x; is a compile-time error, while retunr(x); doesn't complain until link time. Admittedly a minuscule point. (Note, by the way, that K&R I says, on page 23, that The value... is returned... by the return statement... Any expression may occur within the parentheses. This initially led me to believe that the parentheses were required, as others have mentioned they once were; which may account for the misleading wording. It's been corrected in the second edition, to "Any expression may follow return.")
ggg@sunquest.UUCP (Guy Greenwald) (03/27/90)
In article <894@dino.cs.iastate.edu>, hascall@cs.iastate.edu (John Hascall) writes: > > Operator precedence and associativity in C is quite complicated > and somewhat non-intuitive. A few well-placed parentheses can > go a long way toward promoting readability and understanding, > even if they are not strictly necessary.[1] For once, I agree with Robert J. Drabek. If you read his article carefully, you'll see he's making a pedagogic point. A student who is required to use the minimum number of parentheses will have to understand C's precedence rules. After the student leaves his class, he's on his own, but as a teacher, Robert will have done his job. As for the egregious a /= b ? c << 3 & g || f ? e || 2 + ++d & ~c : w : z; the programmer should have broken it up into a separate series of simpler expressions. a /= (b ? ( (((c << 3) & g) || f) ? ( (e || ((2 + ++d) & ~c)) : w ) : z ) ); is not much of an improvement, in my opinion.
boyne@hplvli.HP.COM (Art Boyne) (03/27/90)
In article <19356@megaron.cs.arizona.edu> Robert J. Drabek wrote: >In article <340018@hplvli.HP.COM>, boyne@hplvli.HP.COM (Art Boyne) writes: >> jgk@osc.COM (Joe Keane) writes: >> >Here's my biggest C style peeve. For some reason, many C programmers insist >> >on always putting parentheses around return values, even when they're not >> >> Also, 'while', 'for', 'if', etc., >> all *require* parenthesis, so it's a reasonable habit to acquire. > >But as Joe Keane said, these constructs require the parenthesis for a >particular reason and few people understand that reason. > >Also, Joe Keane made the point that many people put parenthesis in >simply because they see other people do it. And there are those who >believe return is a function and hence required! You "conveniently" left out the centerpoint of my quote: While 'return value;' is legal according to K&R1 (see page 203), *every* example in my copy of the book uses 'return (value);'. Pretty obvious, therefore, why people code that way. Remember that for many of us in industry (vs. universities), C was learned not from college professors, but from reading K&R1 on the job and experimenting with the compilers available. After reading and duplicating many of the examples in the book, the habit of using 'return (value);' was fairly well ingrained *long* before we got to the language specification in the back of the book. Note that K&R1 never states up front that the parentheses are superfluous, and we have the defense that "What's good enough for Dennis Ritchie is good enough for me". >I require my students to use the absolute minimum number of parenthesis >until they have ALL the rules down pat. After leaving my courses (or in >the privacy of their own PC) they'll do whatever feels good, but I will >have done my job as well as I can by getting them to understand these >details. Sorry, but this is one of the pet peeves I have with academia. Rather than wasting your students time worrying about such trivia as few extra parenthesis (excessive over-parenthesization, however, does indicate a conceptual problem), as a potential future employer, I would rather you spend more time teaching the students about algorithms, debugging techniques, and common source-level optimizations, so that, when they do get out into industry, they can do useful work. Particular languages are simply fads that change with time, but the foundation of computer science is the methods/algorithms/etc., that endure. When I was in college, the computer science courses taught (in order) FORTRAN, CDC assembler, Algol, and Snobol. Pascal was still a graduate-level research project, and C was unknown. Since leaving school, I have learned both Pascal and C, as well as 3-4 different assembly languages. A professor who would have tried to make me learn the finer nuances of FORTRAN would have wasted my time. Art Boyne, boyne@hplvla.hp.com
jharkins@sagpd1.UUCP (Jim Harkins) (03/27/90)
In article <19356@megaron.cs.arizona.edu> robert@cs.arizona.edu (Robert J. Drabek) writes: >I require my students to use the absolute minimum number of parenthesis >until they have ALL the rules down pat. After leaving my courses (or in >the privacy of their own PC) they'll do whatever feels good, but I will >have done my job as well as I can by getting them to understand these >details. My God I hope I never ever run into one of your students. Pray tell, what does x = *a->b++ + ++z / 3 << 9^6 + 3 >> 2 ^ 5 <= 98 *~ c % d--; evaluate to? And is it really what the programmer intended? Are you sure? Why penalize a student for trying to make his code both more readable and maintainable? And are you sure they don't get the code working using parens, then re-edit it to remove the 'unneeded' parens? I sure would! -- jim jharkins@sagpd1 We are all aware of the high cost of alcohol abuse. To help solve this problem take this signature to your local liquor store for $1.00 off your next purchase.
news@ism780c.isc.com (News system) (03/27/90)
In article <19356@megaron.cs.arizona.edu> robert@cs.arizona.edu (Robert J. Drabek) writes: >I require my students to use the absolute minimum number of parenthesis >until they have ALL the rules down pat. I would hope you don't fault your students for writing: x = a << (i+j); Here is what Dennis Ritchie says in "The C programming Language, The Bell System Technical Journal, July-August 1978" under the heading "Unfavorable experiences": There are some occasionally suprising operator precedences. For example a >> 4 + 5 shifts right by 9. Marv Rubinstein
barmar@think.com (Barry Margolin) (03/27/90)
In article <689@sagpd1.UUCP> jharkins@sagpd1.UUCP (Jim Harkins) writes: >In article <19356@megaron.cs.arizona.edu> robert@cs.arizona.edu (Robert J. Drabek) writes: >>I require my students to use the absolute minimum number of parenthesis >>until they have ALL the rules down pat. >My God I hope I never ever run into one of your students. Pray tell, what >does > x = *a->b++ + ++z / 3 << 9^6 + 3 >> 2 ^ 5 <= 98 *~ c % d--; That expression has problems, but adding parentheses would hardly solve them. I don't think I'd understand it unless it were broken up into multiple assignment statements, with mnemonic variable names for the temporaries. Alternatively, comments would be nice, and if they were good they would serve as well as mnemonic variables and parentheses. Presumably the author of such a statement originally developed it in a stepwise fashion, which would be mirrored by the multiple statement version. Then he merged them into one statement for performance reasons, and then removed parens for some perverted reason. The comments I mentioned above could just be the original multiple statements! -- Barry Margolin, Thinking Machines Corp. barmar@think.com {uunet,harvard}!think!barmar
boyne@hplvli.HP.COM (Art Boyne) (03/28/90)
hascall@cs.iastate.edu (John Hascall) writes: > Operator precedence and associativity in C is quite complicated > and somewhat non-intuitive. An understatement. ggg@sunquest.UUCP (Guy Greenwald) writes: >For once, I agree with Robert J. Drabek. If you read his article carefully, >you'll see he's making a pedagogic point. A student who is required to use >the minimum number of parentheses will have to understand C's precedence >rules. Phooey - certain of the precedence are so counter-intuitive that after 6-1/2 years of programming in C, I still have a copy of K&R1's precedence chart taped to my wall. Trying to make a student learn it, and be able to reproduce it for a test, is ridiculous. As an employer, I am far more concerned about whether the student understands what a>b ? x : y does than whether he writes it as (a>b) ? (x) : (y). In industry, it costs a *lot* more to find a bug created by omitting a needed pair of parenthesis than it ever will to pay for the keystrokes to put in a pair in a doubtful situation. Art Boyne, boyne@hplvla.hp.com
rli@buster.irby.com (Buster Irby) (03/28/90)
robert@cs.arizona.edu (Robert J. Drabek) writes: >In article <340018@hplvli.HP.COM>, boyne@hplvli.HP.COM (Art Boyne) writes: >> jgk@osc.COM (Joe Keane) writes: >> >Here's my biggest C style peeve. For some reason, many C programmers insist >> >on always putting parentheses around return values, even when they're not >> >required >> Also, 'while', 'for', 'if', etc., >> all *require* parenthesis, so it's a reasonable habit to acquire. >I require my students to use the absolute minimum number of parenthesis >until they have ALL the rules down pat. After leaving my courses (or in >the privacy of their own PC) they'll do whatever feels good, but I will >have done my job as well as I can by getting them to understand these >details. Correct me if I am wrong, but the most import thing you can teach a student is how to *analyze* and *solve* a problem using *all* of the tools at his(her) disposal. Instead, what your students are learning is how to get eye strain trying to figure out which operator takes precedence. You job is to point out all of the features of the language, both good and bad. However, you should not be forcing your *opinion* of whether or not to use those features on your students. After all, aren't you trying to teach them how to make their own decisions? Do you also force your students to write programs that are not indented? Remember, the extra white space used to indent a program is not necessary for the compiler, this feature only applies to the humans. By the way, have any of your students won the Obfuscated C Contest lately? I thought so! :-) -- Buster Irby buster!rli
braun@drivax.UUCP (Kral) (03/29/90)
In article <19356@megaron.cs.arizona.edu> robert@cs.arizona.edu (Robert J. Drabek) writes: [on the subject of parens in a return statement] > >Please, I know parenthesis are sometimes an aid in producing readable >code and they are also clutter which can make for less-readable code. I don't know. return( a > b ? a : b ) ; looks a lot more readable to me than return a > b ? a : b ; Maybe I'm a coding wimp, or maybe I shouldn't use complex statements, but I have (what I think are sound) reasons for doing so, and the former is more readable to me than the latter as it sets off the expression being returned. -- kral 408/647-6112 ...amdahl!drivax!braun "To surrender is to remain in the hands of barbarians for the rest of my life; To fight is to leave my bones exposed in the desert waste" - ancient chinese poem
emuleomo@paul.rutgers.edu (Emuleomo) (03/29/90)
I still don't understand how parenthesis in a <return> stmt makes code harder to read! I think this is just making a mountain out of a molehill. Remember that most C programmers program in other languages too. Most of them require this parenthesis! --Olu -- *Nothing* is hard. If it looks hard, you are looking at it the hard way!
erlkonig@walt.cc.utexas.edu (Christopher North-Keys) (03/29/90)
I found this "gem" on the net somewhere. This strikes me as a good example not to follow, at least in term of commenting. Parenthesization would have helped, but then again, we probably still would have wasted hours figuring out the *meaning* behind the bloody thing, and probably still wouldn't understand the main line inside the loop. Now, there are two ways of looking at this code. The first is the inevitable recollection that C actually has contests congratulating the least-readable code. The second is more subtle: I have yet to find (even in C) a decent way to express the fuctionality of the for() statement in this program, yet due to the language's flexibility the programmer managed it. His *comments* are miserable (nay, sir; they were absent), but the flexibility of a language evidenced by the creation of a new loop idiom is *very* impressive. ...No, I don't code this way either, that's not the point. As to those advocating minimalistic parenthesization, there is always the chance that one's program will be compiled on an errant compiler. The bug could take a *long* time to find. There are also instances in preprocessor macro definitions where lenient parenthesis will mangle code, and let's not forget the possibility of making a mistake -- there are over 15 levels of operator precedence in the K&R C guide. Of course there are those who will *insist* that math expressions, like program sources, are fully self documenting. Example: "Hey, you know that you don't need to comment code, don't you? You really *use* comments? But the good programmers don't *need* them, they just clutter up the code... What kind of programmer *are* you anyway --- bet you use lots of parenthesis too, don't you... What university did you say you attended?... Yeah, I'll just *bet* you did..." Even "lint" likes parenthesis, that must mean something. output: }-1.129-> ./maze 7 ._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._ | ._| . . ._| | |_._._. . ._|_._._._._. ._|_. ._|_._. ._| | . ._|_. | . ._._. | | ._|_| |_. | | | | ._._|_._|_._. . |_. | | | ._._| |_._._._| | ._. ._| . . |_| |_._._._. | ._|_. ._._._. | | ._. |_._. . | ._._| |_. | . ._._._. |_. | |_|_| | | | . |_._| . ._._._| ._._. ._._| | | |_| . | |_. . ._|_|_| ._._. |_._|_| . | | | | |_| |_._| | ._. . | | |_._._| | | | | |_|_. . |_| . | |_| . . ._|_. |_|_. | |_. | |_._._._|_. |_|_| ._._| ._._. ._| . . | ._|_. ._| . ._|_| |_. . | | | | | |_._._._._._._._._._|_._._._._|_._._|_._|_|_._._|_._._|_|_._._._._|_|_._._._._| |}-1.233-> ---------------original program as posted: }-1.130-> cat maze.c char*M,A,Z,E=40,J[40],T[40]; main(C){for(*J=A=scanf(M="%d",&C);--E;J[E]=T[E]=E)printf("._");for(;(A-=Z=!Z)||(printf("\n|"),A=39,C--);Z||printf(M))M[Z]=Z[A-(E=A[J-Z])&&!C&A==T[A]|6<<27<rand()||!C&!Z?J[T[E]=T[A]]=E,J[T[A]=A-Z]=A,"_.":" |"];} ---------------lint's impression of the original code above: }-1.233-> lint maze.c maze.c ============== (1) warning: precedence confusion possible: parenthesize! (1) warning: main() returns random value to invocation environment ============== function returns value which is always ignored printf ---------------reformatted program: }-1.187-> cat ./maze+.c main() { int C; /* number of rows of cells */ char *M; char A, Z, E=40, J[40], T[40]; for(*J = A = scanf(M = "%d", &C) ; --E ; J[E] = T[E] = E) printf("._"); /* top line of first row has been printed * J holds 1,1-39, T holds 0-39, A is 1, E and Z are 0, M -> "%d" * * ONE LINE NESTED LOOP * (the loop I understand, the contents are another matter entirely) * * Z oscillates between 0 (initially) and 1. * On the end of all passes except the last, A=39, C--, "\n|" prints. * On the end of Z==1 passes, A drops, and M is printed. * On the end of passes where Z==1, M is printed. * The loop is terminated when C is dropped to 0. */ for( ; (A -= Z = !Z) || (printf("\n|"), A=39, C--) ; Z || printf(M)) /* The abuse of M requires a GCC compile flag: -fwritable-strings * * Constant: Z A J Z C T J A[J-Z] * Variable: E M[0] M[1] T[A] J[see below] * Derivations: * E <<< A[J-Z] each pass * T[E] <<< T[A] <<< A-Z \ * J[T[A]] <<< E |__only passes printing "_." * J[A-Z] <<< A / * M[Z] is set to "_." or " |". The 1st has side-effects */ M[Z] = Z[ A - ( E = A[J-Z] ) && /* seems (6<<27 < rand()) is true app. 59% of the time */ /* /-------\ //-----\ -------\ */ !C & A == T[A] | 6 << 27 < rand() || !C & !Z ? J[T[E]=T[A]] = E , J[T[A]=A-Z] = A, "_." : " |" ]; } P.S. If anyone ever does figure this puppy out...send me mail, eh? ------------------------------------/\---------------------------------------- Seo: Harp[@Mcc.Com] / \/\ ^*^ Christopher North-Keys Tha mi gu trang a'cluich. / \ \ Assoc. Systems Analyst, MCC --------------------------------(disclaimer)----------------------------------
ka@cs.washington.edu (Kenneth Almquist) (03/29/90)
hascall@cs.iastate.edu (John Hascall) writes: > A few well-placed parentheses can go a long way toward promoting > readability and understanding, even if they are not strictly necessary. > > This mess has "the absolute minimum number of parentheses": > > a /= b ? c << 3 & g || f ? e || 2 + ++d & ~c : w : z; This is the sort of expression that gives C a bad name. > }Please, I know parenthesis are sometimes an aid in producing readable > }code and they are also clutter which can make for less-readable code. > > Extra parenthesization, even full parenthesization need not be > mutually exclusive with readability, that's what whitespace is for! > > a /= (b ? ( > (((c << 3) & g) || f) ? ( > (e || ((2 + ++d) & ~c)) : > w > ) : > z > ) > ); I don't find this version much more readable than the original. Try using "if" rather than "? :" and "||" for flow of control: if (b == 0) a /= z; else if ((c << 3 & g) == 0 && f == 0) a /= w; else if (e == 0) { d++; if ((d + 2 & ~c) == 0) abort(); } I've taken the liberty of replacing the grotesque use of division by zero with a call to abort. This code still hasn't reached the point where it belongs in a C program. The variable names are poorly chosen, and the bit operations are probably a consequence of a bad choice of data representation. And yes, the minimal parenthesis style I used here could probably be improved by a few added parenthesis for the benefit of people who don't remember the priority of the "&" operator. Kenneth Almquist -- "The only light in the room comes from the green screen of my computer monitor and the small red lights on my modem. I turn to check the clock: 3 a.m. `Good,' I think. `Three hours before I have to leave for school. Too bad I didn't have time to do any homework'" - Bill Landreth
peter@ficc.uu.net (Peter da Silva) (03/30/90)
> return( a > b ? a : b ) ; > looks a lot more readable to me than > return a > b ? a : b ; Personally, I prefer to use parentheses to avoid ambiguity: return (a > b) ? a : b; Or better: if (a>b) return a; else return b; But that's another issue. -- _--_|\ `-_-' Peter da Silva. +1 713 274 5180. <peter@ficc.uu.net>. / \ 'U` \_.--._/ v
lucio@proxima.UUCP (Lucio de Re) (04/07/90)
In article <1990Mar26.023758.21002@athena.mit.edu> scs@athena.mit.edu (Steve Summit) writes: >I stopped using parentheses after "return" because I happen to >mistype that particular keyword a lot, and > > retunr x; > >is a compile-time error, while > > retunr(x); > >doesn't complain until link time. Admittedly a minuscule point. Not at all, I think it's a very good point; in fact the best to date. Unfortunately, I like to think of return (); as equivalent to exit (); (how eccentric (a euphemism for perverse) can one get?) so _I_ will stick to return(x); (or retrun(x), my personal misspelling). ---------------------------------------------------------------------- I used to design nuclear reactors and you should see the code that engineers and scientists come up with. Yuuuck! Spaghetti everywhere. -------------------------------------------------- (Kenneth L Moore) - Lucio de Re ...uunet!ddsw1!olsa99!proxima!lucio -------------------------------------------------------- lucio@proxima Disclaimer: He must have been joking!
klatchko@cory.Berkeley.EDU (ron klatchko) (04/10/90)
In article <1273@proxima.UUCP> lucio@proxima.UUCP (Lucio de Re) writes: >In article <1990Mar26.023758.21002@athena.mit.edu> scs@athena.mit.edu (Steve Summit) writes: >> retunr x; >>is a compile-time error, while >> retunr(x); >>doesn't complain until link time. Admittedly a minuscule point. > >Not at all, I think it's a very good point; in fact the best to date. It is a good point, if you are using a compiler that cannot handle prototypes. Otherwise, make sure that your compiler will issue a warning if it you call a function that is not prototyped (in gcc, this can be done using -Wimpilict or -Wall; in Microsoft C, this can be done using -W3). You can then indulge your personal style peeve and still find out about a typo at compile time. ron ------------------------------------------------------------------------------ Ron Klatchko klatchko@cory.Berkeley.EDU ...!ucbvax!cory!klatchko