home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1992 #26 / NN_1992_26.iso / spool / comp / lang / c / 16261 < prev    next >
Encoding:
Internet Message Format  |  1992-11-09  |  2.2 KB
  1. Path: sparky!uunet!ontek!mikey
  2. From: mikey@ontek.com (euphausia superba)
  3. Newsgroups: comp.lang.c
  4. Subject: Re: The Correct Way To Write C if-Statements
  5. Message-ID: <2184@ontek.com>
  6. Date: 9 Nov 92 19:13:08 GMT
  7. References: <140742@lll-winken.LLNL.GOV>
  8. Followup-To: alt.dev.null
  9. Organization: Ontek Corporation -- Laguna Hills, California
  10. Lines: 44
  11.  
  12. I was hoping that I could sit idly by while someone else posted my
  13. opinion about code formatting so that I could appear aloof to this
  14. tired old subject.  Alas, no one (at least not this time around) 
  15. has brought up this viewpoint:
  16.  
  17. Establishing a consistent, company-wide style of code formatting
  18. results in a loss of information.  When several programmers
  19. collaborate on a project, even a source code control system has
  20. difficulty identifying exactly who wrote what statement.  Each
  21. programmer should be free to establish his own style, to serve as a
  22. signature so that in case of a question about the code later, there
  23. is at least some *hint* as to who exactly screwed up, without having
  24. to check out old revisions and compare the modifications (if they
  25. are even available.)
  26.  
  27. So that nobody is tempted to follow this up with the flaws
  28. in my reasoning, I'll mention them here:
  29.  
  30. 1. There are only so many cohesive "styles" available to
  31.    choose from.  After hiring, say, 20 programmers, it's
  32.    almost a certainty that a several will have styles so
  33.    close as to be indistinguishable.
  34.  
  35. 2. Programmers can "disown" code they're ashamed of by rewriting
  36.    it in someone else's style. 
  37.  
  38. 3. Some anal-retents, when given a hunk of code to maintain
  39.    or enhance, will reformat it before beginning work on
  40.    on it anyway, erasing the style-signatures of the previous
  41.    authors and wasting time in the process.
  42.  
  43. 4. The main thesis of advocates of enforced coding styles: that 
  44.    these differing styles lead to unreadable code.
  45.  
  46. But a little "Hey, Bob, did you write this?  Can you tell me if..." 
  47. from time to time is a surprisingly effective productivity tool and
  48. should not be discarded in the name of readability.
  49.  
  50. This is a subject that's been posted to death several times over the
  51. years, and there's about a 50-50 chance I'll end up cancelling this
  52. message anyway.  Followups to alt.dev.null.
  53.  
  54.       the krill
  55.  
  56.