From mboxrd@z Thu Jan  1 00:00:00 1970
X-Spam-Checker-Version: SpamAssassin 3.4.5-pre1 (2020-06-20) on
	ip-172-31-74-118.ec2.internal
X-Spam-Level: 
X-Spam-Status: No, score=-1.9 required=3.0 tests=BAYES_00 autolearn=ham
	autolearn_force=no version=3.4.5-pre1
Date: 4 Jun 93 15:47:20 GMT
From: agate!usenet.ins.cwru.edu!magnus.acs.ohio-state.edu!math.ohio-state.edu!w
upost!emory!sol.ctr.columbia.edu!The-Star.honeywell.com!saifr00.cfsat.honeywell
.com!shanks@ucbvax.Berkeley.EDU  (Mark Shanks)
Subject: Re: McCabe package for Ada?
Message-ID: <1993Jun4.154720.23587@saifr00.cfsat.honeywell.com>
List-Id: <comp.lang.ada>

In article <daniC83348.MJ7@netcom.com> dani@netcom.com (Dani Zweig) writes:

>It turned out that there was a 96% correlation between the Cyclomatic
>Complexity of a module and the number of statements in a module.  The
>link is that Cyclomatic Complexity is almost perfectly correlated with
>the number of decisions in a module, the number of decisions is almost
>perfectly correlated with the number of IFs, and the *density* of IFs
>is quite consistent, with the result that the number of IFs is almost
>perfectly correlated with the number of statements.

As I understand it, the cyclomatic complexity - extended McCabes
is a count of conditions (IFs, ELSEIFs, AND THENs, etc.) in a
procedure + 1. I've verified this on a few (20-30) procedures. 
But it seems you're concluding that the complexity metric would
(could?) be correlated with the number of statements, and I
haven't had that experience. I see you are referring to a 
COBOL/MIS environment; I'm using Ada.

>Needless to say, Cyclomatic Complexity turns out to be an excellent
>predictor of defects -- by virtue of the fact that long modules average
>more defects than short modules.  All of which is to say that people
>who measure Cyclomatic Complexity probably aren't measuring what they
>think they're measuring.  (McCabe's Essential Complexity has its own
>problems, but it's a *somewhat* better measure of the 'messiness' of a
>module's control structure.)

Well, at the risk of appearing hopelessly inept, I have a problem
with high McCabe values as a necessary indicator of procedure
complexity/lack of maitainability. I have procedures that are
logically grouped by function, for example, displaying aircraft
brake antiskid failure messages. There are six possible messages,
plus the condition of blanking the display for invalid data
conditions. I am checking the status of 64 input parameters 
(mostly Booleans) to determine which message/combination of messages
should be displayed. (If XXXXXX and then YYYYY then...)
Based on the nature of this McCabe metric, the count of IFs and
ELSEIFs gets quite high very quickly, yet the code is quite
simple to follow. I have the option of breaking this function up 
into smaller procedures (this procedure has 186 logical lines of
code), but that wouldn't make it any less complicated or more
maintainable. Any suggestions? Should I care if the McCabe is
high but the code is obviously not complex and after exhaustive
testing has no defects?

Mark Shanks
shanks@saifr00.cfsat.honeywell.com