home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1992 #26 / NN_1992_26.iso / spool / comp / lang / c / 16450 < prev    next >
Encoding:
Text File  |  1992-11-13  |  3.0 KB  |  80 lines
  1. Newsgroups: comp.lang.c
  2. Path: sparky!uunet!usc!rpi!psinntp!psinntp!dg-rtp!batman!goudreau
  3. From: goudreau@batman.rtp.dg.com (Bob Goudreau)
  4. Subject: Re: The Correct Way To Write C if-Statements
  5. Message-ID: <1992Nov12.213228.9881@dg-rtp.dg.com>
  6. Sender: nadmroot@dg-rtp.dg.com (nadm root login)
  7. Date: Thu, 12 Nov 92 21:32:28 GMT
  8. References: <140742@lll-winken.LLNL.GOV> <1992Nov6.225622.25460@dg-rtp.dg.com> <hansg.721510062@risken>
  9. Organization: Data General Corporation, RTP, NC
  10. Lines: 68
  11.  
  12. In article <hansg.721510062@risken> hansg@risken.vd.volvo.se (Hans Granqvist) writes:
  13. >goudreau@robin.rtp.dg.com (Bob Goudreau) writes:
  14. >
  15. >->    if ( OpenCode ) ...
  16. >
  17. >-Is anyone else as repelled as I am by the practice of leaving the
  18. >-parentheses surrounded by whitespace on both sides?  Not only does
  19. >-it violate such de-facto standards as K&R or H&S, it goes against
  20. >-common English usage as well ( and if you don't believe that, then
  21. >-tell me what's wrong with this parenthetical question? ) .
  22. >
  23. >Hmm... in my opinion, every person putting two (2) spaces at the end of
  24. >a sentence ('full stop'?) not only breaks a de facto Swedish standard but also
  25. >shows great unsolidity in his language. 
  26.  
  27. "Unsolidity in his language"?  Whatever does that mean?
  28.  
  29. Anway, if I were posting in Swedish, then perhaps I'd put only one
  30. space after each period.  But in English, two following spaces *IS*
  31. the standard (look it up).   And (getting back to the point), I'll
  32. bet that even in Swedish you don't insert gratuitous spaces between
  33. parentheses and the clause which they surround.
  34.  
  35.  
  36. >-Moving on to another topic...
  37. >
  38. >->    if ( SomeDarnThing == TRUE ) ...
  39. >
  40. >-If "SomeDarnThing" (amazing how the whitespace fanatic seems to hate
  41. >-underscores!) is a boolean variable, then what is the point of testing
  42. >-it against TRUE or FALSE?  The following is more concise and easier
  43. >-to read:
  44. >
  45. >-    if (some_darn_thing) ...
  46. >
  47. >
  48. >Aye, relating to your latest remark on coherence with common language
  49. >usage, is your proposed fashion more correct than the other? 
  50.  
  51. I don't understand this comment.  The presence or absence of the
  52. "== TRUE" code has no connection with punctuation conventions at all.
  53. The thing which I find objectionable is the silly testing against
  54. TRUE or FALSE.  Certainly the practice of using
  55.  
  56.     if (condition)
  57.  
  58. instead of
  59.  
  60.     if (condition == 1)  /*  or == TRUE */
  61.  
  62. is well established in C; look at K&R1.  So why add needless
  63. verbiage?
  64.  
  65.  
  66. >And, then, is there the slight casuality that 'TRUE' was defined to, per
  67. >chance, '4711'?
  68.  
  69. In which case there is the large *certainty* that the coder doesn't
  70. know what he is doing! Anyone who defines TRUE and FALSE such that
  71. (! TRUE) isn't equal to FALSE or (! FALSE) isn't equal to TRUE
  72. shouldn't be coding in C.  The only pair of values that meets both
  73. conditions is 1 and 0, and the only mapping that allows use of C's
  74. natural flow-control is when FALSE == 0.
  75.  
  76. ----------------------------------------------------------------------
  77. Bob Goudreau            Data General Corporation
  78. goudreau@dg-rtp.dg.com        62 Alexander Drive    
  79. +1 919 248 6231            Research Triangle Park, NC  27709, USA
  80.