home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1992 #27 / NN_1992_27.iso / spool / comp / lang / c / 16781 < prev    next >
Encoding:
Internet Message Format  |  1992-11-19  |  2.1 KB
  1. Path: sparky!uunet!dtix!darwin.sura.net!sgiblab!munnari.oz.au!metro!atom.ansto.gov.au!teslab!andrew
  2. From: andrew@teslab.lab.oz.au (Andrew Phillips)
  3. Newsgroups: comp.lang.c
  4. Subject: Re: The Correct Way To Write C if-Statements
  5. Message-ID: <4494@teslab.lab.oz.au>
  6. Date: 19 Nov 92 00:34:14 GMT
  7. References: <2184@ontek.com>
  8. Organization: Technology Services, Chief Secretary's Dept, Sydney
  9. Lines: 46
  10.  
  11. mikey@ontek.com (euphausia superba) writes:
  12. : [How a coding conventions should not be enforced because the style
  13. : can be used to identify the author of the code.]
  14.  
  15. With the greatest respect, I submit that the style of code is a very
  16. poor way of identifying an author.  Apart from the flaws that you
  17. mention there is also no guarantee that the programmers will use
  18. different styles or be aware of what other peoples styles are.  Is
  19. there some problem with you compiler that it doesn't accept comments.
  20.  
  21. Proper use of a source code control system would allow you to
  22. identify who wrote at least large chunks of code.  With very small
  23. pieces there would not be enough to code to detect a style anyway.
  24.  
  25. My final question is, why do you need to know who wrote the code, if
  26. it is well written and documented.  In a company I worked for it was
  27. policy that the author of code NOT be identified.  This was to
  28. encourage people to write code just to get the job done and not to
  29. spend a lot of time writing code just to impress others.  Personally
  30. I think there are valid reasons for needing to find who wrote a bit
  31. of code.  Of course, this company is probably very different to yours
  32. - having a high turnover of staff the chances were high that the
  33. original author could not be located anyway.
  34.  
  35. As far as the advantages of code conventions goes I think that
  36. readability can not be emphasized enough.  Not only does it save time
  37. and frustration it can help avoid some nasty bugs.  And after all
  38. most of us use some conventions which would otherwise make software
  39. completely unreadable, although I have seen code like this:
  40.  
  41. f()
  42. {
  43. while (x)
  44. {
  45. i=10;
  46. for (j=1; j<i; ++j)
  47.   {
  48.   if ()
  49.   {  xxx;
  50.      if ()
  51.   {  yyy;
  52.      }}
  53. }
  54. }}
  55. -- 
  56. Andrew Phillips (andrew@teslab.lab.oz.au) Phone +61 (Aust) 2 (Sydney) 287 6551
  57.