home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1992 #31 / NN_1992_31.iso / spool / comp / lang / c / 19089 < prev    next >
Encoding:
Internet Message Format  |  1992-12-31  |  3.4 KB
  1. Path: sparky!uunet!paladin.american.edu!darwin.sura.net!spool.mu.edu!umn.edu!csus.edu!netcom.com!netcomsv!ulogic!hartman
  2. From: hartman@ulogic.UUCP (Richard M. Hartman)
  3. Newsgroups: comp.lang.c
  4. Subject: Re: readable code
  5. Message-ID: <800@ulogic.UUCP>
  6. Date: 31 Dec 92 18:37:00 GMT
  7. References: <1992Dec31.020953.12265@netcom.com>
  8. Organization: negligable
  9. Lines: 106
  10.  
  11. In article <1992Dec31.020953.12265@netcom.com> pdh@netcom.com (Phil Howard ) writes:
  12. >
  13. >BTW, I've had a couple people who I know are fully experienced C programmers
  14. >tell me that they find array subscripting like:
  15. >
  16. >    array [ n ]
  17. >
  18. >harder to read, and insist on something like:
  19. >
  20. >    array[n]
  21. >
  22. >Personally I find the former easier to read, PROVIDED IT FITS.  There is
  23. >not that much difference that I would not squish it to get certain things
  24. >on one line where those things would read better that way.  But I do feel
  25. >I should space things out when it makes it easier to read... it it usually
  26. >does so for *ME*.
  27.  
  28. To continue in this vein you would probably be writing:
  29.  
  30.     func ( arg )
  31.  
  32. and:
  33.  
  34.     if ( cond )
  35.  
  36. Is "if" a function or a keyword?
  37.  
  38. I tend to use spacing as an aid to comprehension.  If a symbol
  39. is alone, I tend to think of it as a variable or keyword, if
  40. followed by a '(', it should be a function, if followed by a
  41. '[' then an array.  so I would write:
  42.  
  43.     func(arg)
  44.  
  45. although I would accept:
  46.  
  47.     func( arg )
  48.  
  49. if forced to.  I *do* like spaces after my commas for "readability",
  50. so:
  51.  
  52.     func(arg1, arg2)
  53.  
  54. would be typical for my style.
  55.  
  56. Otoh I would never write:
  57.  
  58.     if(cond)
  59.  
  60. again, that creates a "visual ambiguity" about whether "if" is
  61. a function.  It would be:
  62.  
  63.     if (cond)
  64.  
  65. in my code.  
  66.  
  67.  
  68. Similarly I would write my array references as:
  69.  
  70.     array[index]
  71.  
  72. Instead of tossing in spaces.  In general I tend to try to
  73. use spacing conventions as they are used in english.  That is,
  74. spaces after commas, but not before; spaces before parenthesis
  75. but not after; etc.  I guess my preference for NOT putting the
  76. space before the paren of a function comes from notations from
  77. scientific & mathematical functions, and functions from other
  78. languages used before I used C (and I still appreciate the
  79. extra clue it gives that the symbol is a function and not
  80. a variable...).
  81.  
  82. Spaces should separate things that should be separated, and not 
  83. separate things that shouldn't.  (how's that for a solopsism!        :)
  84.  
  85. Your code example (sorry I deleted it before deciding to 
  86. refer to it) where you select the array with ?: and then
  87. index it (something like:
  88.  
  89.     ((a < b) ? array1 : array2) [idx] += inc;
  90.  
  91. wasn't it?) I would consider "comprehensible", but not "readable".
  92. To differentiate: conprehensible is something I can understand
  93. after reading it, readable is something I don't have to think
  94. about as I'm scanning over the code.  (maybe what I'm after
  95. should be called "scannable"?)
  96.  
  97. I unfortunately have to sometimes read code that is precicely
  98. the opposite of mine:
  99.  
  100.     if( cond )
  101.  
  102. sheesh!  Imagine trying to read a comment( a parenthetical
  103. comment embedded in another sentance )that used spacing
  104. conventions like that!
  105.  
  106. disclaimer:  All of the above is, of course, IMHO.  And
  107. does not represent the opinion of anyone other than myself
  108. and all other rational programmers.        ;)
  109.  
  110.  
  111. =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
  112. And the men who hold high places    |
  113. must be the ones who start        |    -Richard Hartman    
  114. to mold a new reality            |    hartman@uLogic.COM
  115. closer to the heart!            |
  116.  
  117.