home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1992 #26 / NN_1992_26.iso / spool / comp / lang / c / 16047 < prev    next >
Encoding:
Internet Message Format  |  1992-11-06  |  3.1 KB
  1. Xref: sparky comp.lang.c:16047 comp.software-eng:4167 comp.sys.mac.programmer:18055
  2. Path: sparky!uunet!charon.amdahl.com!pacbell.com!decwrl!decwrl!netcomsv!ulogic!hartman
  3. From: hartman@ulogic.UUCP (Richard M. Hartman)
  4. Newsgroups: comp.lang.c,comp.software-eng,comp.sys.mac.programmer
  5. Subject: Re: Productivity of a C programmer ?
  6. Message-ID: <560@ulogic.UUCP>
  7. Date: 5 Nov 92 23:35:56 GMT
  8. References: <1992Oct29.085752.25264@pilhuhn.ka.sub.org> <Bx3KFK.7Er@cdsmn.mn.org>
  9. Followup-To: comp.lang.c
  10. Organization: negligable
  11. Lines: 66
  12.  
  13. In article <Bx3KFK.7Er@cdsmn.mn.org> wells@cdsmn.mn.org (Rich Wells) writes:
  14. >
  15. >I use a very conservative means of measuring LOCs.  Blank lines do
  16. >not count, lines with just a bracket do not count, and comments
  17. >do not count.  When I count lines of code, I count just lines of
  18. >real code.  In my case, this means about 1/4 of the lines in a
  19. >source file count as LOCs.  Bummer.  I don't measure LOCs for
  20. >productivity bragging rights, I do it to get a useful measure.
  21. >
  22. >As for comments, I don't count them as LOCs because the bulk of
  23. >meaningful documentation is not in the code itself, but in
  24. >separate documents where I can incorporate drawing to help explain
  25.  
  26. I have a program for counting lines of code that produces a summary
  27. that includes the raw data:
  28.  
  29.     # lines of active code 
  30.     # lines of code conditionally compiled out (see above)
  31.     # lines of comments
  32.     # blank lines
  33.     # lines total
  34.  
  35. and some derived "scores" (my own opinons, not from any book
  36. on software analysis or anything):
  37.  
  38.     code density = (nActive / nTotal) * 100;
  39.     text tensity = 100.0 - ((nBlank/nTotal)*100)
  40.     code/comment ratio = (nActive / (nActive+nComments)) * 100
  41.  
  42. (all calculations done in floating point).
  43.  
  44. Code density is what percentage of the file is "real" code.
  45.  
  46. Text density shows how readable the format is (no spaces 
  47. between separate routines, major blocks of code, comments, etc gives 
  48. a high density i.e. "wall of text" effect).
  49.  
  50. Code/comment ratio shows how well documented the code is.  A low
  51. ratio you may have been spending more time explaining what you were
  52. doing than doing it.  A high ratio may mean that it would be hard
  53. for someone else to jump in and do maintenance.
  54.  
  55. Each of these values were based on my whim of what I thought might
  56. be useful.  No flames on "that one is useless" please.  However, I
  57. am certainly open to suggestions about other metrics to add to the
  58. summary.        :)
  59.  
  60. I process #if/#else/#endif for literal values (1 or 0) and
  61. (if I remember properly, it's been a while) single level symbolic
  62. interpretations (#define DEBUG 1/#if DEBUG) but not yet for compound 
  63. (#if 1 || DEBUG).
  64.  
  65. I consider conditionaly compiled out code important because you
  66. DID spend time developing that debugging code, and it may be
  67. useful in the future if you #if it back in.
  68.  
  69. Sorry, but I don't (currently) handle lines consisting of "{" or "}" alone
  70. (with or without comments) as anything other than a line of code, but perhaps 
  71. I should include that sort of thing.
  72.  
  73.         -Richard Hartman
  74.         hartman@ulogic.COM
  75.  
  76. =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
  77. I am just a figment of your imagination...
  78.             ...what does that say about *your* mental health?
  79.