From: throopw@sheol.UUCP (Wayne Throop)
Newsgroups: comp.lang.c,comp.software-eng,comp.sys.mac.programmer
Subject: Re: Productivity of a C programmer ?
Summary: suggested alternative to various flavors of line counts
Date: 07 Nov 92 00:12:35 GMT

: From: hartman@ulogic.UUCP (Richard M. Hartman)
: Message-ID: <560@ulogic.UUCP>
: I have a program for counting lines of code that produces a summary
: that includes the raw data:
:         # lines of active code
:         # lines of code conditionally compiled out (see above)
:         # lines of comments
:         # blank lines
:         # lines total
: [...] I am certainly open to suggestions about other metrics to add
: to the summary.                :)

A bit easier to gather than, say, McCabe or other metrics, but
still probably quite a bit more useful than line counts are

          # total number of identifiers
          # total number of unique identifiers
          # total number of C (or whatever language) keywords
          # total number of unique C (or whatever language) keywords

and statistics based on these such as

          # histogram of number of words at each frequency
          # average, mean, standard deviation, etc,etc, of this histogram

Just a bit more difficult might be

          # total (and total unique) operators
          # total (and total unique) literal values

(I say a bit more difficult, because scanning for identifier-like
things and looking up keywords is easier than actually parsing out
the operators and several types of literal notation...)

:: From: hartman@ulogic.UUCP (Richard M. Hartman)
:: Message-ID: <560@ulogic.UUCP>
:: Each of these values were based on my whim of what I thought might
:: be useful.  No flames on "that one is useless" please.
: From: lott@bogner.informatik.uni-kl.de (Christopher Lott AGSE)
: Message-ID: <1992Nov6.112137.10887@uklirb.informatik.uni-kl.de>
: You developed these metrics with some goal in mind.  I know you did,
: else you wouldn't have developed them.  Make the goal explicit.  Write
: it down.  Decide what you're trying to achieve (your goal).

Well, in my case, the notion for my suggested metrics comes from the
method I often use to try to get an understanding of new code.  I
generate a hypertexty cross reference keyed on identifier.  For this
purpose, I include words in comments in the cross reference, but other
than that, the general notion is much like the various "tags" programs
for emacs, vi, etc.  I leave comments out of my suggested metrics, since
they don't increase the complexity of the program per se. 

As code is browsed, I can skip to where names are defined, but almost as
important, to other places where they are used, or talked about in
comments, with a few mouseclicks.  Further, I have in front of me
evidence of how often a given name is used throughout the code I'm
examining.  I can often pick out key concepts in the code by examining
the most frequently mentioned global names. 

Therefore, though I don't know how the metrics I suggest really
correspond to development time, number of requirements, bug density,
customer satisfaction, and other important matters, I know that for me,
they *do* tend to correspond to how long it will take me to
*understand* a given chunk of code.
--
Wayne Throop  ...!mcnc!dg-rtp!sheol!throopw