home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1992 #26 / NN_1992_26.iso / spool / comp / lang / c / 16302 < prev    next >
Encoding:
Internet Message Format  |  1992-11-10  |  3.2 KB
  1. Path: sparky!uunet!munnari.oz.au!manuel.anu.edu.au!huxley!tal691
  2. From: tal691@huxley.anu.edu.au (Tonio Loewald)
  3. Newsgroups: comp.lang.c
  4. Subject: A Modest Proposal
  5. Date: 11 Nov 92 01:43:22 GMT
  6. Organization: Australian National University
  7. Lines: 65
  8. Message-ID: <tal691.721446202@huxley>
  9. References: <1992Oct29.085752.25264@pilhuhn.ka.sub.org> <Bx3KFK.7Er@cdsmn.mn.org> <560@ulogic.UUCP>
  10. NNTP-Posting-Host: 150.203.2.12
  11.  
  12. >>As for comments, I don't count them as LOCs because the bulk of
  13. >>meaningful documentation is not in the code itself, but in
  14. >>separate documents where I can incorporate drawing to help explain
  15.  
  16. My modest proposal is that a programmer SHOULD count lines of comments
  17. towards the mystic productivity value (whatever it is). Sure, you
  18. can argue (as shown below) that TOO MANY COMMENTS can be a bad
  19. thing. But, so can TOO MUCH CODE (or, in the case of some programmers,
  20. *any* code).
  21.  
  22. Whether you count comments separately from "real" code is a separate
  23. issue. You could start discounting simple assignment statements
  24. or counting lines involving nested function calls with casting as
  25. either 2 lines of code or -10 lines of code depending on your
  26. outlook. Or defining 10 lines of assembler as 3 lines of "code"
  27. or whatever.
  28.  
  29. The important point is that if you DON'T count comments, that 
  30. means that you don't think of them as VALUABLE. This reflects
  31. a dangerous mindset.
  32.  
  33. >Code/comment ratio shows how well documented the code is.  A low
  34. >ratio you may have been spending more time explaining what you were
  35. >doing than doing it.  A high ratio may mean that it would be hard
  36. >for someone else to jump in and do maintenance.
  37.  
  38. Again -- I don't think this is any more true than saying that if
  39. there's a lot of code, the program must be badly written. Sometimes
  40. a single assignment statement needs a LOT of documentation. (Eg.
  41. "don't touch this assignment statement unless you FULLY understand
  42. what it does. A synopsis follows...")
  43.  
  44. Simple arithmetic can't tell good comments from bad any more than
  45. it can tell good code from bad.
  46.  
  47. Anyone out there using WEB like to comment on any of this?
  48.  
  49. >Each of these values were based on my whim of what I thought might
  50. >be useful.  No flames on "that one is useless" please.  However, I
  51. >am certainly open to suggestions about other metrics to add to the
  52. >summary.        :)
  53.  
  54. >I process #if/#else/#endif for literal values (1 or 0) and
  55. >(if I remember properly, it's been a while) single level symbolic
  56. >interpretations (#define DEBUG 1/#if DEBUG) but not yet for compound 
  57. >(#if 1 || DEBUG).
  58.  
  59. >I consider conditionaly compiled out code important because you
  60. >DID spend time developing that debugging code, and it may be
  61. >useful in the future if you #if it back in.
  62.  
  63. >Sorry, but I don't (currently) handle lines consisting of "{" or "}" alone
  64. >(with or without comments) as anything other than a line of code, but perhaps 
  65. >I should include that sort of thing.
  66.  
  67. Interesting to consider the effects on programmer "productivity" of using
  68. different languages, formatting, naming conventions, and so on.
  69.  
  70. Tonio 
  71.  
  72. -- 
  73. Tonio Loewald            | Ph  06 290 1594 | 13 Sabine Cl. Garran
  74. tal691@huxley.anu.edu.au | Fax 06 290 1595 | ACT 2605   AUSTRALIA
  75. "You can lie/You can cry/For all the good it'll do you, you can
  76. die/But when it's done/And the police come/And they lay you down
  77.