home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1992 #26 / NN_1992_26.iso / spool / comp / lang / c / 16132 < prev    next >
Encoding:
Internet Message Format  |  1992-11-08  |  3.6 KB
  1. Xref: sparky comp.lang.c:16132 comp.software-eng:4189 comp.sys.mac.programmer:18119
  2. Path: sparky!uunet!cis.ohio-state.edu!zaphod.mps.ohio-state.edu!sol.ctr.columbia.edu!ira.uka.de!math.fu-berlin.de!news.netmbx.de!Germany.EU.net!mcsun!sunic!psinntp!psinntp!dg-rtp!sheol!throopw
  3. From: throopw@sheol.UUCP (Wayne Throop)
  4. Newsgroups: comp.lang.c,comp.software-eng,comp.sys.mac.programmer
  5. Subject: Re: Productivity of a C programmer ?
  6. Summary: suggested alternative to various flavors of line counts
  7. Message-ID: <721104893@sheol.UUCP>
  8. Date: 07 Nov 92 00:12:35 GMT
  9. References: <560@ulogic.UUCP> <1992Nov6.112137.10887@uklirb.informatik.uni-kl.de>
  10. Lines: 66
  11.  
  12. : From: hartman@ulogic.UUCP (Richard M. Hartman)
  13. : Message-ID: <560@ulogic.UUCP>
  14. : I have a program for counting lines of code that produces a summary
  15. : that includes the raw data:
  16. :         # lines of active code
  17. :         # lines of code conditionally compiled out (see above)
  18. :         # lines of comments
  19. :         # blank lines
  20. :         # lines total
  21. : [...] I am certainly open to suggestions about other metrics to add
  22. : to the summary.                :)
  23.  
  24. A bit easier to gather than, say, McCabe or other metrics, but
  25. still probably quite a bit more useful than line counts are
  26.  
  27.           # total number of identifiers
  28.           # total number of unique identifiers
  29.           # total number of C (or whatever language) keywords
  30.           # total number of unique C (or whatever language) keywords
  31.  
  32. and statistics based on these such as
  33.  
  34.           # histogram of number of words at each frequency
  35.           # average, mean, standard deviation, etc,etc, of this histogram
  36.  
  37. Just a bit more difficult might be
  38.  
  39.           # total (and total unique) operators
  40.           # total (and total unique) literal values
  41.  
  42. (I say a bit more difficult, because scanning for identifier-like
  43. things and looking up keywords is easier than actually parsing out
  44. the operators and several types of literal notation...)
  45.  
  46. :: From: hartman@ulogic.UUCP (Richard M. Hartman)
  47. :: Message-ID: <560@ulogic.UUCP>
  48. :: Each of these values were based on my whim of what I thought might
  49. :: be useful.  No flames on "that one is useless" please.
  50. : From: lott@bogner.informatik.uni-kl.de (Christopher Lott AGSE)
  51. : Message-ID: <1992Nov6.112137.10887@uklirb.informatik.uni-kl.de>
  52. : You developed these metrics with some goal in mind.  I know you did,
  53. : else you wouldn't have developed them.  Make the goal explicit.  Write
  54. : it down.  Decide what you're trying to achieve (your goal).
  55.  
  56. Well, in my case, the notion for my suggested metrics comes from the
  57. method I often use to try to get an understanding of new code.  I
  58. generate a hypertexty cross reference keyed on identifier.  For this
  59. purpose, I include words in comments in the cross reference, but other
  60. than that, the general notion is much like the various "tags" programs
  61. for emacs, vi, etc.  I leave comments out of my suggested metrics, since
  62. they don't increase the complexity of the program per se. 
  63.  
  64. As code is browsed, I can skip to where names are defined, but almost as
  65. important, to other places where they are used, or talked about in
  66. comments, with a few mouseclicks.  Further, I have in front of me
  67. evidence of how often a given name is used throughout the code I'm
  68. examining.  I can often pick out key concepts in the code by examining
  69. the most frequently mentioned global names. 
  70.  
  71. Therefore, though I don't know how the metrics I suggest really
  72. correspond to development time, number of requirements, bug density,
  73. customer satisfaction, and other important matters, I know that for me,
  74. they *do* tend to correspond to how long it will take me to
  75. *understand* a given chunk of code.
  76. --
  77. Wayne Throop  ...!mcnc!dg-rtp!sheol!throopw
  78.