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 21:44:30 GMT
From: dog.ee.lbl.gov!network.ucsd.edu!swrinde!cs.utexas.edu!hermes.chpc.utexas.
edu!cfi.org!dogface!oakhill!cydonia.sps.mot.com!alanw@ucbvax.Berkeley.EDU  (Ala
n R. Weiss)
Subject: Re: McCabe package for Ada?
Message-ID: <C849q6.7rB@oakhill.sps.mot.com>
List-Id: <comp.lang.ada>

In article <1993Jun4.154720.23587@saifr00.cfsat.honeywell.com> shanks@saifr00.c
fsat.honeywell.com (Mark Shanks) writes:

...

>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

I can't speak for why the mccabe algorithm rates this as high complexity,
but from a logic perspective consider this:  the use of many, many
IF xxxx THEN yyyy statements indicates a LOT of logic has to be
correlated and checked.  You are essentially testing on a state within
a (hopefully) finite state machine, which is just fraught with opportunities
for defects.  While the CODE may be easy to understand, the LOGIC may
not be (especially when you need to use multiple IF and NOT's in
combination to get to the proper state check).  I've seen OS code
at deep levels (kernel) that does this, and it was a bitch to debug
and fix defects.  So, from an intuitive perspective, a high McCabe
number DOES correlate, in this case, to a higher probability of defects.

Really, I just McCabe numbers to give me an idea of where I should
concentrate testing and possibly re-work in development.


-- 
  _ Alan R. Weiss  Motorola-Semiconductor Products Sector, RISC Software
_| ~-. 6501 William Cannon Dr. West, MD-OE112, Austin, Texas USA 78735
\, *_} alanw@pets.sps.mot.com or alanw@cydonia.sps.mot.com | Voi: 512-891-6003
  \(   DISCLAIMER:  I do not speak for Motorola, Inc.      | Fax: 512-891-3798