Re: McCabe package for Ada?

Re: McCabe package for Ada?

[dog.ee.lbl.gov!network.ucsd.edu!usc!howland.reston.ans.net!europa.eng.gte]

In article <raj2.737741040@Isis.MsState.Edu> raj2@Isis.MsState.Edu (rex allan j
ones) 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..." |            
-------------------------------------------------------------------

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"

Re: McCabe package for Ada?

[David Boyd]

In article <1993May18.192447.9259@saifr00.cfsat.honeywell.com> shanks@saifr00.c
fsat.honeywell.com (Mark Shanks) writes:
>Who is using McCabe, and why? 
We are.  We are utilizing the tools currently for two purposes.  One is to
gather some type of complexity and quality metrics for software.  These 
metrics can be used to support costing and estimates when inheriting legacy
software.  The other use we are making of the software is for the Tuning
phase of an Evolutionary Prototyping Lifecycle.  High values for the various
metrics tend to indicate modules which should be looked at for tuning.  Several
organizations are using the metrics for supporting structured testing and
looking at the path coverages of their testing.  Other uses are selective
re-engineering (modules with high complexity tend to have high error rates),
and reduncy elimination (modules with similar values tend to be similar).

>What values are construed as "acceptable",
>"requires further investigation", and "this code is rejected"? 

	This depends entirely on your organization and what limits
you want to set out.  I am of the belief that there are some algorithms or
functions that are inherently complex (the example I use is regular expression
compilation/matching).  Some constructs such as consectutive case statements
generate abnormally high cyclomatic complexities.  My general feeling is that
these are primarily indicators of where to concentrate reviews/walkthroughs.
The following were the ranges I used on a recent
project for cyclomatic, essential, and design.  All of these were given with
the caveat that after inspection an informed cost/benefits analysis on 
whether or not the module would be re-written would be done.

		Cyclomatic	Essential	Design
Good		   <10		   <5		  <8
Acceptable	   <50		   <10		  <16
Marginal	   <100	           <100		  <100
Unacceptable	   100+		   100+           100+

>How were these values derived? Enquiring minds want to know...
	The best reference for this is the National Bureau of Standards
publication NBS Special Publication 500-99 "Structured Testing: A Software
Testing Methodology Using the Cyclomatic Complexity Metric".  This explains
the theory and math behind Cyclomatic and Essential.  Design complexity is
derived from Cyclomatic complexity and is the count of basis paths through
a module which interact with other modules. 


-- 
David W. Boyd	             UUCP:     uunet!sparky!dwb
Sterling Software IMD        INTERNET: dwb@IMD.Sterling.COM
1404 Ft. Crook Rd. South     Phone:    (402) 291-8300 
Bellevue, NE. 68005-2969     FAX:      (402) 291-4362

Re: McCabe package for Ada?

[sgi!fido.asd.sgi.com!dblues!jackr]

In article <C78rKq.57z@oakhill.sps.mot.com>, alanw@williams.sps.mot.com writes:

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

Careful with that approach: if it's recently written, or if it's
causing problems, you might want to rewrite it.  But if it ain't
presently broke, no _way_ do you want to fix this one: you probably
haven't a *clue* what it really does, or how.

I've encountered (in a former job) high cyclomatic modules with an
established history of more-or-less working, where we decided the best
approach was to wall the thing off and avoid looking at it - even to
the extent of some fairly complex head-standing to work around its
idiosyncracies.  We took that course, because our first reaction was
to rewrite it, and that was an utter disaster (thank heaven for
version control!).


Jack Repenning		      M/S 1-875	     jackr@wpd.sgi.com
Silicon Graphics, Inc.	       x3-3027      Off:(415) 390-3027
Visual Magic Division			    Fax:(415) 390-6056

Re: McCabe package for Ada?

[cis.ohio-state.edu!magnus.acs.ohio-state.edu!usenet.ins.cwru.edu!howland.]

In article <1tbvt4$2m3@fido.asd.sgi.com> jackr@dblues.wpd.sgi.com (John Jack Re
penning) writes:
>
>In article <C78rKq.57z@oakhill.sps.mot.com>, alanw@williams.sps.mot.com writes
:
>
>> Mark asks a REALLY good question:  just what the $%^&* is McCabe's
>> number useful for?  I've found the following uses:
>> ...
>> 2.  Candidates for rewrites
>
>Careful with that approach: if it's recently written, or if it's
>causing problems, you might want to rewrite it.  But if it ain't
>presently broke, no _way_ do you want to fix this one: you probably
>haven't a *clue* what it really does, or how.

Lemme get this straight:  you have some code.  Its your code.
The author doesn't remember what it does, or has long since gone
off to ostensibly greener pastures.  You don't have a clue what
it does.  So, you ignore it.  Hmmmmm .....

>I've encountered (in a former job) high cyclomatic modules with an
>established history of more-or-less working, where we decided the best
>approach was to wall the thing off and avoid looking at it - even to
>the extent of some fairly complex head-standing to work around its
>idiosyncracies.  We took that course, because our first reaction was
>to rewrite it, and that was an utter disaster (thank heaven for
>version control!).

Well, hell, Jack, I didn't say re-write the thing NOW.  But sure
as hell if you got some crusty ol' code that seems to work but
has McCabe numbers way up there (like, say 100 or above), you are
going to have to deal with it SOME DAY.  Unless you are working
in a completely stagnant world (which I know you're not -- heh heh).

Hell yes, if you're not using rcs or cvs or something for source
code control, you shouldn't even be bothering with McCabe or
much of anything.  You should go back to your sandbox and play with
the nice dump truck .....  :-)

>
>Jack Repenning		      M/S 1-875	     jackr@wpd.sgi.com
>Silicon Graphics, Inc.	       x3-3027      Off:(415) 390-3027
>Visual Magic Division			    Fax:(415) 390-6056

Clearly SGI is NOT one of these places.
--
  _ 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@maze.sps.mot.com| Voi: 512-891-6003
  \(   DISCLAIMER:  I do not speak for Motorola, Inc.  | Fax: 512-891-3798

	"Where there is no vision, people perish" - Proverbs 29:18

Re: McCabe package for Ada?

[Wes Groleau X7574]

In article <raj2.737741040@Isis.MsState.Edu> raj2@Isis.MsState.Edu (rex allan j
ones) writes:
>	Could someone please point me in the direction of a metrics package
>to compute McCabe's Cyclomatic Complexity for Ada programs?

Logiscope, from Verilog.
Or AdaDL, from SSD (?)
Or check the Ada Software Repository for something free.

Somone else (I hate "vi") wrote:
>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...

McCabe scores are not by themselves a very useful indication of Ada quality.
However, they can be of some use.  When someone hands me 2500 lines of 
code written by the guy that just quit, I look first at the routines with the
highest McCabe scores.  Almost always, if the score is over twenty, I can 
bring it down to 15 or less with some thoughtful re-design.  Not everyone
can make sense out of spaghetti code like that, so I see it as a "service" to
those that come after me--even if the code was already meeting its requirements
(of course I keep the old version for safety :-)  )

As far as what the values SHOULD be:  I have had to work on code written by
many other people.  Consequently I have a good idea of who writes "good stuff"
and who writes "bad stuff"  So I can get a list of the McCabe scores for all
of Fred's units in one list, all of Frieda's in another, etc. and compare.
The averages are usually QUITE different.

Wes G.

P.S. One thing McCabe doesn't show is what I call "hidden" complexity.
Hidden, because it doesn't show on a flow chart or path graph.  This kind of
complexity is produced by a technique more than one of my former colleagues
was fond of:  That of declaring lots of "flag" variables, and using them to
control branching at a point far away from where they were set.  I'd like
to see someone come up with a McCabe-like metric where if dotted lines are
drawn on a control graph connecting the setting of one of these flags with
all tests that depend on that setting, the metric would be affected by 
these lines and their nodes.  Whew! What's the complexity metric of that last
sentence?!?!? 

Re: McCabe package for Ada?

[agate!howland.reston.ans.net!darwin.sura.net!haven.umd.edu!news.umbc.edu!]

On the topic of McCabe complexity, groleau@e7sa.crd.ge.com (Wes Groleau
X7574) writes:

>McCabe scores are not by themselves a very useful indication of Ada quality.
>However, they can be of some use.

>P.S. One thing McCabe doesn't show is what I call "hidden" complexity.
>Hidden, because it doesn't show on a flow chart or path graph.  This kind of
>complexity is produced by a technique more than one of my former colleagues
>was fond of:  That of declaring lots of "flag" variables, and using them to
>control branching at a point far away from where they were set.

While a high McCabe score usually indicates a problem area, a low score
does not necessarily indicate a lack of one. The tradeoff for high
complexity may be an increase in the number of modules, to no benefit
(and often detriment).

Consider the following degenerate case:

	case X is  -- assume X : Integer range 1..4
	when 1 => Do_Something;
	when 2 => Do_Something_Else;
	when 3 => Do_Something_Even_Different;
	when 4 => Do_Yet_A_Fourth_Thing;
	end case;

This statement would add 3 to the complexity of a module containing it.

It could be replaced with the following roughly equivalent code:

	procedure Check_1 is
	begin
	   if X=1 then -- yes, X globally visible for the sake of
	               -- example
	      Do_Something;
	   else
	      Check_2;
	   end if;
	end Check_1;

	procedure Check_2 is
	begin
	   if X=2 then
	      Do_Something_Else;
	   else
	      Check_3;
	   end if;
	end Check_2;

	procedure Check_3 is
	begin
	   if X=3 then
	      Do_Something_Even_Different;
	   else
	      Do_Yet_A_Fourth_Thing;
	   end if;
	end Check_3;

The above scheme results in no added complexity to the module containing
the original case statement, now replaced by a call to Check_1. Each
called module has complexity 2, cleverly eluding the McCabe complexity <
10 check.

The above example is not meant to be realistic, but I have seen cases in
actual code that sure do come close. 

The point of this post is to say that McCabe complexity analysis is
useful, but should be supplemented by a suite of tools to look at code
from other perspectives. The cyclomatic complexity measure, _by itself_,
tells you nothing (as Wes pointed out), especially if a development
community knows that it is the only metric being applied (then the above
transformation is done solely for the purposes of reducing the complexity
score).

-- 
Mike Berman
University of Maryland, Baltimore County	Fastrak Training, Inc.
berman@umbc.edu					(301)924-0050

Re: McCabe package for Ada?

[David Boyd]

In article <C7AIDs.K3@crdnns.crd.ge.com>, groleau@e7sa.crd.ge.com (Wes Groleau
X7574) writes:

|> P.S. One thing McCabe doesn't show is what I call "hidden" complexity.
|> Hidden, because it doesn't show on a flow chart or path graph.  This kind of
|> complexity is produced by a technique more than one of my former colleagues
|> was fond of:  That of declaring lots of "flag" variables, and using them to
|> control branching at a point far away from where they were set.  I'd like
|> to see someone come up with a McCabe-like metric where if dotted lines are
|> drawn on a control graph connecting the setting of one of these flags with
|> all tests that depend on that setting, the metric would be affected by 
|> these lines and their nodes.  Whew! What's the complexity metric of that
|> last
|> sentence?!?!? 
|> 
	Actually the McCabe folks have come up with some metrics for just
that situation.  The first is global data complexity (gv(G)) which 
calculates the number of paths through a module which touch global data.
Another metric is user data complexity (uv(G)) which looks at the 
complexity of a module with respect to a single user data element.  Both
of these are extremely usefull to me both from a quality analysis point of
view as well as from a maintenance point of view.  This is especially
usefull if a tool will display the flow graph of all functions which
reference a data element and highlight the paths which reference the
element.  This would make it extremely easy to determine what tests needed
to be run when a given variable changes.

	Another complexity measure they came up with is pathological complexity
 (pv(G))
which measures those truely awfull conditions in code
such as branches into loops or decisions.  You know the stuff you shoot
people for or would only expect from a 10 year olds first program.
-- 
David W. Boyd	             UUCP:     uunet!sparky!dwb
Sterling Software IMD        INTERNET: dwb@IMD.Sterling.COM
1404 Ft. Crook Rd. South     Phone:    (402) 291-8300 
Bellevue, NE. 68005-2969     FAX:      (402) 291-4362

Re: McCabe package for Ada?

[David Boyd]

In article <1te87gINNt5f@umbc7.umbc.edu>, berman@umbc.edu (Mike Berman) writes:

|> The point of this post is to say that McCabe complexity analysis is
|> useful, but should be supplemented by a suite of tools to look at code
|> from other perspectives. The cyclomatic complexity measure, _by itself_,
|> tells you nothing (as Wes pointed out), especially if a development
|> community knows that it is the only metric being applied (then the above
|> transformation is done solely for the purposes of reducing the complexity
|> score).
	I have to agree with Mike here.  No single metric can define
complexity.  You must look at a number of different factors/metrics and
look for several bad cases together.  For instance if I have a module with
two consectutive case statements each with 10 seperate cases my cyclomatic
complexity is going to be close to 100.  However if I look at essential
complexity it will be 1.  

	In Mike's example, the problem would be indicated by high S0 and
S1 metrics (program design complexity and program integration complexity).
S1 is specifically the number of integration tests (or linearly independent
subtrees) for the program.
-- 
David W. Boyd	             UUCP:     uunet!sparky!dwb
Sterling Software IMD        INTERNET: dwb@IMD.Sterling.COM
1404 Ft. Crook Rd. South     Phone:    (402) 291-8300 
Bellevue, NE. 68005-2969     FAX:      (402) 291-4362

Re: McCabe package for Ada?

[mole-end!mat]

In article <1993May19.220953.20443@sparky.imd.sterling.com>, dwb@IMD.Sterling.C
OM (David Boyd) writes:
> In article <C7AIDs.K3@crdnns.crd.ge.com>, groleau@e7sa.crd.ge.com (Wes Grolea
u
> X7574) writes:
 
> 	Actually the McCabe folks have come up with some metrics for just
> that situation.  ...  pathological complexity (pv(G))
> which measures those truely awfull conditions in code
> such as branches into loops or decisions.  You know the stuff you shoot
> people for or would only expect from a 10 year olds first program.

I'm curious: has anyone run it on Duff's Device?
-- 
 (This man's opinions are his own.)
 From mole-end				Mark Terribile

 mat@mole-end.matawan.nj.us, Somewhere in Matawan, NJ

Re: McCabe package for Ada?

[Alex Blakemore]

In article <1993May24.003302.27291@mole-end.matawan.nj.us> mat@mole-end.matawan
.nj.us writes:
> has anyone run it on Duff's Device?
which is?
-- 
Alex Blakemore       alex@cs.umd.edu        NeXT mail accepted
--------------------------------------------------------------
"Without an engaged and motivated human being at the keyboard,
the computer is just another dumb box."      William Raspberry

Re: McCabe package for Ada?

[pipex!uknet!glasgow!unix.brighton.ac.uk!wjmc]

alex@cs.umd.edu (Alex Blakemore) writes:
> In article <1993May24.003302.27291@mole-end.matawan.nj.us> mat@mole-end.mataw
an.nj.us writes:
> > has anyone run it on Duff's Device?
> which is?

	switch (n&7) {
		do {
	case 0 :	*dst = *src++;
	case 7 :	*dst = *src++;
	case 6 :	*dst = *src++;
	case 5 :	*dst = *src++;
	case 4 :	*dst = *src++;
	case 3 :	*dst = *src++;
	case 2 :	*dst = *src++;
	case 1 :	*dst = *src++;
		} while ((n-=8) > 0);
	}

 as implemented by Tom Duff. There was an article or three discussing it
in comp.lang.c a while back.
-- 
# Bill Crawford aka *Cuddly_Cactus*  BSc (Hons) Computer Science Year Two #
# JANET wjmc@uk.ac.bton.{unix,vms} | Elsewhere wjmc@{unix,vms}.bton.ac.uk #
# Any view that I express is not necessarily those of Brighton University #

Re: McCabe package for Ada?

[Wes Groleau X7574]

In article <1993May24.003302.27291@mole-end.matawan.nj.us> mat@mole-end.matawan
.nj.us writes:
>In article <1993May19.220953.20443@sparky.imd.sterling.com>, dwb@IMD.Sterling.
COM (David Boyd) writes:
>> In article <C7AIDs.K3@crdnns.crd.ge.com>, groleau@e7sa.crd.ge.com (Wes Grole
au
>> X7574) writes:
 
I did not write what follows, in case anyone cares.

>> 	Actually the McCabe folks have come up with some metrics for just
>> that situation.  ...  pathological complexity (pv(G))
>> which measures those truely awfull conditions in code
>> such as branches into loops or decisions.  You know the stuff you shoot
>> people for or would only expect from a 10 year olds first program.

This is NOT the situation I was talking about.  I was talking about code
that "fools" a control analyzer into giving it a low complexity rating.  
Instead of having ridiculously complex decisions and convoluted nesting, it
has "simple" one or two level control structures.  Unfortunately, it's not any
easier to understand, because it's sixteen pages long and the coding thought
process goes like this:
LOOP
  "Hmm, I'm gonna need to make a decision based on these two fields sometime
       further down the file, so I'll check the condition now and throw the
       answer into this boolean (or enumerated, or integer) variable."
  "OK, now I need to loop the number of times I saved in...which scratch
       variable did I put that in?"
  "And inside this loop I need to create and save another control value
       for the decision in the exception handler..."
  "Now I need a case statement on the variable I assigned by calling that
       subprogram back there ...
  [ more of the same ]
  exit LOOP and hope it works when I can no longer figure out where I am...
END LOOP

If I had a nickel for the number of times somebody said "I don't know why
I did that.  Must be needed somewhere else." ...

Wes

Re: McCabe package for Ada?

[David Boyd]

In article <C7nIy3.312@crdnns.crd.ge.com>, groleau@e7sa.crd.ge.com (Wes Groleau
X7574) writes:
|> In article <1993May24.003302.27291@mole-end.matawan.nj.us>
|> mat@mole-end.matawan.nj.us writes:
|> >In article <1993May19.220953.20443@sparky.imd.sterling.com>,
|> dwb@IMD.Sterling.COM (David Boyd) writes:
|> >> In article <C7AIDs.K3@crdnns.crd.ge.com>, groleau@e7sa.crd.ge.com (Wes
|> Groleau
|> >> X7574) writes:
|>  
|> I did not write what follows, in case anyone cares.
|> 
|> >> 	Actually the McCabe folks have come up with some metrics for just
|> >> that situation.  ...  pathological complexity (pv(G))
|> >> which measures those truely awfull conditions in code
|> >> such as branches into loops or decisions.  You know the stuff you shoot
|> >> people for or would only expect from a 10 year olds first program.
|> 
|> This is NOT the situation I was talking about.  I was talking about code
|> that "fools" a control analyzer into giving it a low complexity rating.  
|> Instead of having ridiculously complex decisions and convoluted nesting, it
|> has "simple" one or two level control structures.  Unfortunately, it's not
|> any
|> easier to understand, because it's sixteen pages long and the coding thought
|> process goes like this:
|> LOOP
|>   "Hmm, I'm gonna need to make a decision based on these two fields sometime
|>        further down the file, so I'll check the condition now and throw the
|>        answer into this boolean (or enumerated, or integer) variable."
|>   "OK, now I need to loop the number of times I saved in...which scratch
|>        variable did I put that in?"
|>   "And inside this loop I need to create and save another control value
|>        for the decision in the exception handler..."
|>   "Now I need a case statement on the variable I assigned by calling that
|>        subprogram back there ...
|>   [ more of the same ]
|>   exit LOOP and hope it works when I can no longer figure out where I am...
|> END LOOP
|> 
|> If I had a nickel for the number of times somebody said "I don't know why
|> I did that.  Must be needed somewhere else." ...

	I am not certain about how my response above got fitted with the
situation that Wes is writing about,  it was intended to go with different
posting. (I probably screwed up and followed up the wrong article).

	In any case, I also dread the type of code that Wes is talking
about.  In the case Wes is talking about the metric needed is the cyclomatic
complexity of a module in relation to some set of data elements.  Basically
it would be a count of the number of paths through the the module which touch
one or more of the data elements.  For data elements local to the module, this
would be very tough to automate computation of since you would only
care about some sub-set of the local variables (i.e. you really don't care
much about loop counters) and choosing that subset would require examining
the software.  I would look at values of this number which were close to or
equal to the modules total cyclomatic complexity as being an inditcator that
something might be wrong.  In any case, this type of situation is again
very tough to detect automatically.  About the only thing that can be done
in Wes's case (assuming you have already decided to look at the module) is 
to break out your trusty data cross reference browser and figure out where that
"somewhere else" is located.

  The case I find even more apalling and
which makes the software even harder to maintain is when the variables Wes
is talking about are global and the setting and testing of the variables is
done in multiple modules.  The advantage this case has is that the complexity
of a module can be computed with respect to a set of variable based on the
variable's scoping.  Since, the scope of a variable can be easily determined
via static analysis this type of metric could be easily computed automatically.

	This whole discussion only goes further to re-enforce a point I have
long accepted that there is no single metric which will tell good code from
bad code and that the best one can hope for is a set of metrics which when
taken together can be used to help detect most cases.  In any case you will
never detect all cases of unmaintainable, untestable, etc code. Given a
set of metrics most good programmers could write some module(s) which look
good to the metrics but which are poor in a number of other ways.  This is
why there is no substitute for a good thorough examine of the code by several
people for detecting that sort of flawed engineering.

-- 
David W. Boyd	             UUCP:     uunet!sparky!dwb
Sterling Software IMD        INTERNET: dwb@IMD.Sterling.COM
1404 Ft. Crook Rd. South     Phone:    (402) 291-8300 
Bellevue, NE. 68005-2969     FAX:      (402) 291-4362

Re: McCabe package for Ada?

[Laurence VanDolsen]

In article <C7nIy3.312@crdnns.crd.ge.com> groleau@e7sa.crd.ge.com (Wes Groleau 
X7574) writes:
>If I had a nickel for the number of times somebody said "I don't know why
>I did that.  Must be needed somewhere else." ...

I can't help it, I have to tell this story.

Once upon a quarter of a century ago we were developing a major release
of a satellite control package every six months.  All of the code was in
assembler.  During final integration, and operational use, any defects
found were fixed with OCTAL patches.  For each new release, all of the
old defects had to be corrected in the assembler source.  This job was
usually given to one of the developers who had just rotated into
developemnt from field installation and test.  Sooo, this guy
incorporated the patches literally.  Where there had been a jump out of
a routine to an empty place in memory to incorporate a fix that would
not fit in line, he jumped out.  Where a convenient instruction, or even
operand field had been used as a mask value, he put a label on that
instruction, or its operand, and used it.  

I think this is now refered to as, "He just didn't get it."

Re: McCabe package for Ada?

[dog.ee.lbl.gov!network.ucsd.edu!sdd.hp.com!portal!lisburn!jaime]

>|> LOOP
>|>   "Hmm, I'm gonna need to make a decision based on these two fields sometim
e
>|>        further down the file, so I'll check the condition now and throw the
>|>        answer into this boolean (or enumerated, or integer) variable."
>|>   "OK, now I need to loop the number of times I saved in...which scratch
>|>        variable did I put that in?"
>|>   "And inside this loop I need to create and save another control value
>|>        for the decision in the exception handler..."
>|>   "Now I need a case statement on the variable I assigned by calling that
>|>        subprogram back there ...
>|>   [ more of the same ]
>|>   exit LOOP and hope it works when I can no longer figure out where I am...
>|> END LOOP
>|> 
>|> If I had a nickel for the number of times somebody said "I don't know why
>|> I did that.  Must be needed somewhere else." ...
>
>	I am not certain about how my response above got fitted with the
>situation that Wes is writing about,  it was intended to go with different
>posting. (I probably screwed up and followed up the wrong article).
>
>	In any case, I also dread the type of code that Wes is talking
>about.  In the case Wes is talking about the metric needed is the cyclomatic
>complexity of a module in relation to some set of data elements.  Basically
>it would be a count of the number of paths through the the module which touch
>one or more of the data elements.  For data elements local to the module, this
>would be very tough to automate computation of since you would only
>care about some sub-set of the local variables (i.e. you really don't care
>much about loop counters) and choosing that subset would require examining
>the software.  I would look at values of this number which were close to or
>equal to the modules total cyclomatic complexity as being an inditcator that
>something might be wrong.  In any case, this type of situation is again
>very tough to detect automatically.  About the only thing that can be done
 ^^^^ ^^^^^ ^^ ^^^^^^ ^^^^^^^^^^^^^

I'm not sure I understand the situation completely, (or the metrics)
but in the example above one of the problems was a lack of locality of 
reference. This is rather routinely calculated in optimizing compilers 
(called the use-definition tree). They want to know when they do and don't 
need to have space for a variable (especially when the variable lives in 
a register).

The compiler calculates this data for it's own uses, but the information is
there and could be massaged for purposes of producing metrics, or warning 
messages, if that's desirable. In fact, for the compiler, widespread uses of a 
variable in some cases might as well be separate variables, but to the human 
eye it's not apparent(which is the problem, of course).

I'm not a metrics person at all, but I know something about compilers.
I hope this helps. Is there some part of this discussion I didn't follow ?

Jaime "Former Compiler Guy" Cordera

>
>-- 
>David W. Boyd	             UUCP:     uunet!sparky!dwb
>Sterling Software IMD        INTERNET: dwb@IMD.Sterling.COM
>1404 Ft. Crook Rd. South     Phone:    (402) 291-8300 
>Bellevue, NE. 68005-2969     FAX:      (402) 291-4362

-- 
-----------------------------------------------------------------------------
Jaime Cordera                                     jaime@vertex.com
Vertex Semiconductor                              (408)456-8900x2337
A Toshiba Subsidiary         <your pithy saying here...>

Re: McCabe package for Ada?

[Dani Zweig]

By way of digression -- I had occasion, some time ago, to analyze the 
complexity of a large number (something over five thousand) of modules,
using McCabe's metrics and others.  (This was not an Ada environment --
something I'll comment on below.)

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.

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.)

The main caveat is that I was analyzing COBOL/MIS software.  There
is strong a-priori reason to believe that in an Ada/Embedded
environment, the correlation between Cyclomatic Complexity and
module length would be high -- but not that high.

-----
Dani Zweig
dani@netcom.com

   The inability of snakes to count is actually a refusal, on their part,
    to appreciate the Cardinal Number system. -- "Actual Facts"

Re: McCabe package for Ada?

[agate!usenet.ins.cwru.edu!magnus.acs.ohio-state.edu!math.ohio-state.edu!w]

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

Re: McCabe package for Ada?

[Dani Zweig]

shanks@saifr00.cfsat.honeywell.com (Mark Shanks):
>>It turned out that there was a 96% correlation between the Cyclomatic
>>Complexity of a module and the number of statements in a module...

>As I understand it, the cyclomatic complexity - extended McCabes
>is a count of conditions (IFs, ELSEIFs, AND THENs, etc.) in a
>procedure + 1...

Close.  Multiple entries, multiple exits and non-binary conditions
will boost the figure a bit, but #conditionals+1 is a good approximation.

>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.

No, I'm reporting the 96% correlation as an observation, not a deduction
(other studies have reported similar results), and only invoking the formula
to give an intuitive explanation.  

I'm sure the correlation is weaker in your environment, but I'll be
very surprised if it's below 80%.  This doesn't call for judgment
calls on your part:  Measure v(G) and the number of statements for
a large number of modules, and simply compute the correlation.

>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 agree:  It doesn't measure what most people who use it think it does.

-----
Dani Zweig
dani@netcom.com

   It was mentioned on CNN that the new prime number discovered
   recently is four times bigger then the previous record.
				-- John Blasik

Re: McCabe package for Ada?

[Ala n R. Weiss]

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

Re: McCabe package for Ada?

[dog.ee.lbl.gov!network.ucsd.edu!swrinde!cs.utexas.edu!csc.ti.com!tilde.cs]

In article <1993Jun4.154720.23587@saifr00.cfsat.honeywell.com> shanks@saifr00.c
fsat.honeywell.com (Mark Shanks) writes:
>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.

No, he said they MEASURED that correlation, using actuals from their
code.

>I see you are referring to a 
>COBOL/MIS environment; I'm using Ada.

As I read what he posted, he was in an environment that was using Ada to
do COBOL/MIS kinds of things.  Sort of doesn't matter: McCabe complexity
is not going to be affected significantly by Ada vs. COBOL.  (You have
learned my darkest secret: years ago, I learned COBOL, as well as the
more "mainstream" languages like Pascal, FORTRAN, LISP, Ada, and C.)

>>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?

Some twenty hears ago, Halstead (sp?) originated what came to be
called "software physics", but which we now call "metrics".  The air
was removed forcibly from their sails when someone showed that ALL of
their different measures, each one supposedly measuring some fundamentally
different aspect of program complexity, were strongly correlated with
each other and with number of source lines of code.

What this, and the McCabe measure, and the old-fashioned ruler test all
seem to say is that bigger modules TEND to be problem sources, and TYPICALLY
need more attention for quality, maintainability, reliability, and flavor.

Exceptions exist on both ends of the scale.  No metric is a substitute for
a functioning set of brain cells.

As for your particular procedure: if you currently have it partitioned
into one decision tree that calls one of a large handful of procedures,
then you have probably done all that you can.  The test is this: next week,
the systems engineers will come to you with a new special case that you
need to tack in.  How easy will it be to make the mod and test the modified
module?  If we repeat this five times (or fifty), what will the result
look like?

Re: McCabe package for Ada?

[Kevin Sullivan]

shanks@saifr00.cfsat.honeywell.com (Mark Shanks) writes:
> . . .
>As I understand it, the cyclomatic complexity - extended McCabes
>is a count of conditions (IFs, ELSEIFs, AND THENs, etc.) in a
>procedure + 1. 

The following may be of interest.  

Gill, G. K. and Kemerer, C. F., "Cyclomatic complexity density and software
maintenance productivity," IEEE Transactions on Software Engineering 17,12,
pp. 1284--8, Dec. 1991.

"The cyclomatic complexity metric is a measure of the maximum number of
linearly independent circuits in a program control graph. . . .  a simple
transformation of the metric is investigated whereby the cyclomatic
complexity is divided by the size of the system in source statements.
-- 
Kevin Sullivan
Department of Computer Science and Engineering, FR-35
University of Washington
Seattle, WA 98195 

Re: McCabe package for Ada?

[David Boyd]

In article <1993Jun3.194721.23315@vertex.com>, jaime@vertex.com (Jaime Cordera)
writes:

|> >something might be wrong.  In any case, this type of situation is again
|> >very tough to detect automatically.  About the only thing that can be done
|>  ^^^^ ^^^^^ ^^ ^^^^^^ ^^^^^^^^^^^^^
|> 
|> I'm not sure I understand the situation completely, (or the metrics)
|> but in the example above one of the problems was a lack of locality of 
|> reference. This is rather routinely calculated in optimizing compilers 
|> (called the use-definition tree). They want to know when they do and don't 
|> need to have space for a variable (especially when the variable lives in 
|> a register).
|> 
	What I was refering to that was hard to detect was what variables
where of significance in caclulating the cyclomatic complexity with reguard
to data.  Simple variables such a loop counters, and indexes would contribute
significantly to the number of paths but in the example provided would not
be significant.

	The "Locality of Reference" measure that Jamie mentions was the concept
 I was
referring to in a subsequent post.  Basically the metric
would look a the distance between references by counting the number of
nodes in the flow graph between references.  One could use this number to
look at an average locality,  the number of references which exceed a 
threshold.  Since straight line code on a flow graph is a would map to a single
node a variable referenced on opposite ends of the block would have a locality
metric of one.  This would be reasonable since the real problem is
following references to variables through complex loops and branches.  A 
standard for measuring the distance between references when there is complex
logic involved  since there would be multiple paths with different links
possible.  I would reccomend that the locality metric use the longest path
since in practice that is the path which is hardest to trace through.

	Jaime is very correct about compilers doing this type of calculation
all the time.  By looking at a locality measure like is being discussed one
could determine not only when situations such a what Wes described occure, 
but also would get a general idea (it would only be general since many other
factors are involved including hardware) of how well a given piece of
software could be optimized.  It would be interesting to do a study where
pieces of poorly written unstructure code and well written structured code whic
h
do the same things where run through optimizers.  Then look to see
if there is statistical coorrelations between certain metrics (like McCabe's
and the locality of reference we are discussing) and how well the resulting
object code is optimized (i.e. size and speed).  Since most good compilers
eliminate things like dead code and extranous assignments some degree
of the unstructuredness would be optimized out.  
the same
not be a problem 
-- 
David W. Boyd	             UUCP:     uunet!sparky!dwb
Sterling Software IMD        INTERNET: dwb@IMD.Sterling.COM
1404 Ft. Crook Rd. South     Phone:    (402) 291-8300 
Bellevue, NE. 68005-2969     FAX:      (402) 291-4362

Re: McCabe package for Ada?

[sgi!fido.asd.sgi.com!dblues!jackr]

In article <1993Jun4.154720.23587@saifr00.cfsat.honeywell.com>, shanks@saifr00.
cfsat.honeywell.com writes:

> 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.

Over large amounts of code, the correlation has been measured, and has
been found to be high.  I don't believe this invalidates the ideas
here.  Rather, it demonstrates that people tend to write code of a
particular complexity density - why should that be surprising?  The
important question is, when you use the tools to learn a new style, do
you produce code which is "better" in some way (such as having fewer
defects, being easier to maintain, or being easier to verify)?  I
haven't seen any published research on this, by my own experience say
the tools can indeed help many programmers develop better judgement
and style.

> I have a problem with high McCabe values as a necessary indicator of
> procedure complexity/lack of maitainability.

You should.  No one should be telling you that this is a necessary (or
sufficient) indicator.  The claim is that it's a common indicator,
that it ought to raise your suspicions: it's an aid to your good
judgement, not a quick-fix.

> (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.

There really are cases where a string of conditionals are completely
independent, and don't add to any real complexity; there really are
cases where they interact in ways that make the superficially-simple
code a disaster area.  At the very least, this is an area where you
should apply your judgement (as you have), and might well be justified
in ignoring the numbers.

"Essential" and "Design" complexity numbers attempt to count things
that are more helpful in these situations, but you still have to treat
them as warning flags, not gospel.

> Should I care if the McCabe is high but the code is obviously not
> complex and after exhaustive testing has no defects?

Absolutely not.  Just be convinced in your own mind as to why the
numbers raised a false flag, just in case there really is cause for
concern.


Jack Repenning		      M/S 1-875	     jackr@wpd.sgi.com
Silicon Graphics, Inc.	       x3-3027      Off:(415) 390-3027
Visual Magic Division			    Fax:(415) 390-6056