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=-0.9 required=3.0 tests=BAYES_00,TO_NO_BRKTS_PCNT autolearn=no autolearn_force=no version=3.4.5-pre1 Date: 4 Jun 93 06:24:07 GMT From: netcomsv!netcom.com!dani@decwrl.dec.com (Dani Zweig) Subject: Re: McCabe package for Ada? Message-ID: List-Id: 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"