home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1992 #31 / NN_1992_31.iso / spool / comp / lang / c / 19057 < prev    next >
Encoding:
Text File  |  1992-12-30  |  2.2 KB  |  62 lines
  1. Newsgroups: comp.lang.c
  2. Path: sparky!uunet!spool.mu.edu!umn.edu!csus.edu!netcom.com!pdh
  3. From: pdh@netcom.com (Phil Howard )
  4. Subject: readable code
  5. Message-ID: <1992Dec31.020953.12265@netcom.com>
  6. Organization: Netcom - Online Communication Services  (408 241-9760 guest) 
  7. Date: Thu, 31 Dec 1992 02:09:53 GMT
  8. Lines: 52
  9.  
  10. I just saw a posting on comp.lang.c on the usage of ?: and one of the
  11. replies noted that you could use ?: to select the choice of function
  12. to be called with one set of argument list.
  13.  
  14. C has a lot of features other languages just don't have.  In those endless
  15. debates over what language is best, a lot of people frequently tell me that
  16. certain features (and they happen to point out the ones C has that others
  17. do not) are "not (easily) readable".
  18.  
  19. In one debate I had, someone tried to convince me that:
  20.  
  21.     x += 3;
  22.  
  23. was not readable while:
  24.  
  25.     x = x + 3;
  26.  
  27. was readable.
  28.  
  29. To me, an expression like:
  30.  
  31.     ( ( n < midway ) ? array_a : array_b ) [ n ] += k;
  32.  
  33. is perfectly readable.
  34.  
  35. What I am interested in finding out is what is a good way to specifically
  36. characterize CODE READABILITY (specific to the C language).
  37.  
  38. I think we should assume readability by a fully experienced C programmer.
  39. Just because something does not exist in other languages or fields of
  40. study does not, IMHO, justify attacking it as unreadable WITHIN the C
  41. language, so I am not interested in that aspect of the question.
  42.  
  43. BTW, I've had a couple people who I know are fully experienced C programmers
  44. tell me that they find array subscripting like:
  45.  
  46.     array [ n ]
  47.  
  48. harder to read, and insist on something like:
  49.  
  50.     array[n]
  51.  
  52. Personally I find the former easier to read, PROVIDED IT FITS.  There is
  53. not that much difference that I would not squish it to get certain things
  54. on one line where those things would read better that way.  But I do feel
  55. I should space things out when it makes it easier to read... it it usually
  56. does so for *ME*.
  57. -- 
  58. /************************************************************************\
  59. | Phil Howard,  pdh@netcom.com,  KA9WGN    Spell protection?  "1(911)A1" |
  60. | "It's not broken... it's just functionally challenged" --Phil and Pete |
  61. \************************************************************************/
  62.