Re: McCabe package for Ada?

[dog.ee.lbl.gov!overload.lbl.gov!agate!howland.reston.ans.net!ux1.cso.uiuc]

In article <1993May18.192447.9259@saifr00.cfsat.honeywell.com> shanks@saifr00.c
fsat.honeywell.com (Mark Shanks) writes:
>In article <raj2.737741040@Isis.MsState.Edu> raj2@Isis.MsState.Edu (rex allan 
jones) writes:
>>	Could someone please point me in the direction of a metrics package
>>to compute McCabe's Cyclomatic Complexity for Ada programs?
>>	Thank you!
>>--
>
>Not that this answers your question, but since you bring it up :)
>
>Who is using McCabe, and why? What values are construed as "acceptable",
>"requires further investigation", and "this code is rejected"? How
>were these values derived? Enquiring minds want to know...
>-------------------------------------------------------------------
>| Mark Shanks                          |           
>| Principal Engineer                   |    All opinions mine,  
>| 777 Displays                         |        of course.
>| shanks@saifr00.cfsat.honeywell.com   |          
>| "We have such sights to show you..." |            
>-------------------------------------------------------------------


Mark asks a REALLY good question:  just what the $%^&* is McCabe's
number useful for?  I've found the following uses:

1.  Project Estimation in porting - if a large number of modules score
a lot higher (i.e. more complex - say, over an arbitrary limit of 8
for OS code), then I know my understanding of the product to be ported
is going to take longer.  I factor that into my schedules.

2.  Candidates for rewrites - or at least careful analysis - I once
had a module score over 200!!!  Turns out this database engine code
WAS terrible, and should have been re-written.  It never was, but that
was because the Development manager was a dolt. ;-)

3.  Candidates for a lot more testing - if some modules score higher
numbers (again, more complex), and if the quantity of my test assertions
is relatively low, then I probably haven't covered enough functionality
in my testing.  Maybe.  Point is, I should take a second look, right?

4.  May be troublesome code, i.e. defect-prone - McCabes sez that
he has seen a 99% correlation between high scores and quantity of
defects detected in those modules.  I mean, say he's lying (which is
doubtful), and the correlation factor is only, say, 70%.  That's still
worth investigating.  In my experience, though, really bad numbers mean
something's wrong - algorithmically, data type wise, whatever.

5.  Candidates for code inspection - its always been problemmatic:
how do you inspect EVERY line of source code?  I dunno - I haven't
found I could.  But if you could come up with some technique for inspecting
code based upon some sampling, then you could invoke the 80/20 rule.
McCabe's numbers are ONE factor (NOT the only one - always code inspect
interface code and header files!).

Here's the rub:  some code NEEDS to be complex.  I've seen OS code that
scored high numbers, but upon code inspection using Fagan/Gilb Inspections
methodology we'all determined, "hey, this is OK - more than a few of
us understand it (now), and it needs to be this weird."  But certainly
you want to look at it.

All IMHO, of course.  Anyone who uses metrics incorrectly should be
sentenced to death.  Just kidding.  A little.

--
  _    Alan R. Weiss		Motorola Semiconductor Products Sector
_| ~-. alanw@pets.sps.mot.com	RISC Software, Bldg. H, Dept. SD653
\, *_} alanw@maze.sps.mot.com	MD-OE112, Oak Hill, Austin, Texas USA
  \(  				Phone Ext. 6003 (512-891-6003)

"Would you tell me, please, which way I ought to go from here?"
"That depends a good deal on where you want to get to," said the Cat
"I don't much care where---", said Alice.
"Then it doesn't matter which way you go", said the Cat.
"--so long as I get *somewhere*," Alice added as an explanation.
"Oh, you're sure to do that," said the Cat, "if you only walk long enough."

                -- Lewis Carroll
                "Alice in Wonderland"