home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1992 #27 / NN_1992_27.iso / spool / comp / lang / c / 17042 < prev    next >
Encoding:
Text File  |  1992-11-23  |  2.3 KB  |  53 lines
  1. Newsgroups: comp.lang.c
  2. Path: sparky!uunet!think.com!snorkelwacker.mit.edu!enterpoop.mit.edu!bloom-picayune.mit.edu!news
  3. From: scs@adam.mit.edu (Steve Summit)
  4. Subject: Achilles and the Tortoise (was: The Correct Way To Write C if-Statements)
  5. Message-ID: <1992Nov23.163316.1551@athena.mit.edu>
  6. Sender: news@athena.mit.edu (News system)
  7. Nntp-Posting-Host: adam.mit.edu
  8. Organization: none, at the moment
  9. References: <1992Nov12.212728.8864@dg-rtp.dg.com> <hansg.722248402@risken>
  10. Date: Mon, 23 Nov 1992 16:33:16 GMT
  11. Lines: 40
  12.  
  13. In article <hansg.722248402@risken>, hansg@risken.vd.volvo.se (Hans Granqvist) writes:
  14. > goudreau@batman.rtp.dg.com (Bob Goudreau) writes:
  15. >> The thing which I find objectionable is the silly testing against
  16. >> TRUE or FALSE.  Certainly the practice of using
  17. >>     if (condition)
  18. >> instead of
  19. >>     if (condition == 1)  /*  or == TRUE */
  20. >> is well established in C; look at K&R1.  So why add needless
  21. >> verbiage?
  22. > 
  23. > ...I must object strongly to your
  24. > saying that there's only need to test 'if' or 'if not'. Some FAQ I think
  25. > once said (it still does, I presume) that there is a LOGICAL difference
  26. > to 0, '\0', and NULL. So why not test against the correct values?
  27.  
  28. The comp.lang.c FAQ list indeed discusses differences between 0
  29. and NULL ('\0' is a red herring in that context), and suggests
  30. that using NULL where appropriate may show good stylistic intent.
  31. Testing a single (conceptually boolean) variable explicitly
  32. against TRUE or FALSE is relatively harmless (depending on how
  33. the variable was set).  Of the more general case "if(<expr> == TRUE)",
  34. however, the FAQ list has this to say:
  35.  
  36.     ...the test
  37.  
  38.         if((a == b) == TRUE)
  39.  
  40.     will work as expected (as long as TRUE is 1), but it is
  41.     obviously silly.  In general, explicit tests against TRUE and
  42.     FALSE are undesirable, because some library functions (notably
  43.     isupper, isalpha, etc.) return, on success, a nonzero value
  44.     which is _not_ necessarily 1.  (Besides, if you believe that
  45.     "if((a == b) == TRUE)" is an improvement over "if(a == b)", why
  46.     stop there?  Why not use "if(((a == b) == TRUE) == TRUE)"?)  A
  47.     good rule of thumb is to use TRUE and FALSE (or the like) only
  48.     for assignment to a Boolean variable, or as the return value
  49.     from a Boolean function, never in a comparison.
  50.  
  51.                         Steve Summit
  52.                         scs@adam.mit.edu
  53.