Path: utzoo!utgpu!news-server.csri.toronto.edu!rpi!crdgw1!uunet!pdn!locke
From: locke@paradyne.com (Richard Locke)
Newsgroups: comp.software-eng
Subject: Re: WANTED: "C" code line counter program
Message-ID: <1991Apr1.174913.29320@pdn.paradyne.com>
Date: 1 Apr 91 17:49:13 GMT
References: <350@tslwat.UUCP> <12630@pucc.Princeton.EDU> <1991Mar28.145235.14313@grep.co.uk>
Sender: news@pdn.paradyne.com (News Subsystem)
Organization: AT&T Paradyne, Largo, Florida
Lines: 45
Nntp-Posting-Host: nike

In article <1991Mar28.145235.14313@grep.co.uk> frank@grep.co.uk (Frank Wales) writes:
>In article <12630@pucc.Princeton.EDU> EGNILGES@pucc.Princeton.EDU writes:

There has been a lot of work done in software metrics that addresses
the topics & concerns that have been discussed (extensively) in this thread.

>>Case in point: program A falls thru the cracks as a "noncomplicated
>>program" because it has only ONE statement.  It fails.  The
...
>...is there any work on enumerating programs at the token
>level, a sort of "component count" metric?  This, at least, would
>be an honest assessment of the fundamental syntactic pieces,
>whatever that might be worth.  (Yes, I'm a "metric sceptic".)

The Halstead "Software Science" family of metrics are based on the number
of operators and operands.  They give you some sense of a body of code's
"size".  The other major metrics family, McCabe's "Cyclomatic Complexity"
metrics, asseses complexity based on a program's flow of control.

Both these classes of metrics help evaluate "size" and "complexity", and
address the "but what about *this* program!" cases that have been kicked
around.

The best introduction these metrics of which I'm aware is in 
"A Software Metrics Tutorial", which is included with the UX-Metric
or PC-Metric tools that Set Labs sells.  Unfortunately, I don't
believe it's available anywhere else.  These XX-Metric tools
read a body of code and spit out various metrics including McCabe
and Halstead stuff, LOC, semi-colons, comment lines, estimated
number of errors, estimated time to develop, etc.
They are cheap, too -- cheaper to your company than having a programmer
mess around for a couple of days coding and perfecting a line counter ;-)

Anyway, I suggest that people interested in metrics, but unfamiliar with
the McCabe and Halstead metrics, do some investigation.

If you're more interested in software productivity than software complexity,
I further suggest that you get and read Jones' "Programming Productivity".
This has an excellent discussion as to why LOC is bad for productivity
measures.


-dick "just a satisfied customer of UX-Metric"

p.s.  Send me mail if you want pointers or references to the stuff I mention...