Path: utzoo!utgpu!news-server.csri.toronto.edu!clyde.concordia.ca!uunet!tut.cis.ohio-state.edu!snorkelwacker!bloom-beacon!daemon
From: scs@adam.mit.edu (Steve Summit)
Newsgroups: comp.lang.c
Subject: Re: Re: Determining C Complexity
Message-ID: <1990Aug7.023330.19705@athena.mit.edu>
Date: 7 Aug 90 02:33:30 GMT
References: <1050@ashton.UUCP> <7990016@hpopd.HP.COM>
Sender: daemon@athena.mit.edu (Mr Background)
Reply-To: scs@adam.mit.edu (Steve Summit)
Organization: Thermal Technologies, Inc.
Lines: 40

In article <7990016@hpopd.HP.COM> daves@hpopd.HP.COM (Dave Straker) writes:
>henry@zoo.toronto.edu (Henry Spencer) / 10:45 pm  Aug  4, 1990 / writes:
>>If you want to measure bugs, performance, and maintenance ease, there are
>>better metrics.  Like number of bugs, timing figures, and maintenance
>>man-hours.  Admittedly, there are a lot of variables involved, and it is
>>hard work to measure these things well.  Running a program to determine
>>the cyclomatic complexity of the code is much easier...
>
>Yes, I suppose the basis of this discussion is McCabe. Nevertheless
>his measure is a *tool*. It can be run over a lot of files quickly to
>flag *potential* trouble spots. The final judgement must be human.

Henry and Dave both have good arguments, and neither of them
is really wrong.  I think the argument boils down to a similar
tautology as does the occasional attempt to ban the goto
statement: good programmers write good code without metrics, and
might have good reason to write code which a metric says is "bad"
(presumably such code is backed up by comments which the metric
can't see).  Struggling programmers will probably find ways to
write lousy code even in the presence of metrics (and the lousy
code may even manage to have low "complexity" scores).  The
metrics may help to manage a project staffed by struggling
programmers (and there are probably a lot of them out there) but
they aren't going to magically save that project, or the rest of
the industry.  (And, to be fair, no one in this discussion has
claimed that they would.)

Someone asked about real studies attempting to correlate
complexity metric scores with "real" code quality (measured by
programmer assessment, or bug reports, or something).  I remember
a paper from the Pacific Northwest Software Quality Conference in
Portland in 1985 or 1986 describing a study which tried to do
just that.  Rather sheepishly, the researchers had to admit that,
of all the metrics studied, the only valid correlation was seen
in the case of the control, namely the wc metric.  Of course,
metrics were rather new then; some may have gotten better by
now...

                                            Steve Summit
                                            scs@adam.mit.edu