Page 189 - DCAP305_PRINCIPLES_OF_SOFTWARE_ENGINEERING

Unit 9: Metrics

For example, McCabe originally recommended exempting modules consisting of single multiday Notes
decision (“switch” or “case”) statements from the complexity limit. The multiday decision
issue has been interpreted in many ways over the years, sometimes with disastrous results.
Some naive developers wondered whether, since multiway decisions qualify for exemption
from the complexity limit, the complexity measure should just be altered to ignore them. The
result would be that modules containing several multiday decisions would not be identified as
overly complex. One developer started reporting a “modified” complexity in which cyclomatic
complexity was divided by the number of multiday decision branches. The stated intent of this
metric was that multiday decisions would be treated uniformly by having Complexity limitation
affects the allocation of code among individual software modules, limiting the amount of code
in any one module, and thus tending to create more modules for the same application. Other
than complexity limitation, the usual factors to consider when allocating code among modules
are the cohesion and coupling principles of structured design: The ideal module performs a
single conceptual function, and does so in a self-contained manner without interacting with
other modules except to use them as subroutines. Complexity limitation attempts to quantify an
“except where doing so would render a module too complex to understand, test, or maintain”
clause to the structured design principles. This rationale provides an effective framework for
considering exceptions to a given complexity limit.
Rewriting a single multi-way decision to cross a module boundary is a clear violation of structured
design. Additionally, although a module consisting of a single multi-way decision may
Require many tests, each test should be easy to construct and execute. Each decision branch can
be understood and maintained in isolation, so the module is likely to be reliable and maintainable.
Therefore, it is reasonable to exempt modules consisting of a single multi-way decision statement
from a complexity limit. Note that if the branches of the decision statement contain complexity
themselves, the rationale and thus the exemption does not automatically apply. However, if
all branches have very low complexity code in them, it may well apply. Although constructing
“modified” complexity measures is not recommended, considering the maximum complexity of
each multi-way decision branch is likely to be much more useful than the average. At this point
it should be clear that the multi-way decision statement exemption is not a bizarre anomaly
in the complexity measure but rather the consequence of a reasoning process that seeks a
balance between the complexity limit, the principles of structured design, and the fundamental
properties of software that the complexity limit is intended to control. This process should serve
as a model for assessing proposed violations of the standard complexity limit. For developers
with a solid understanding of both the mechanics and the intent of complexity limitation, the
most effective policy is: “For each module, either limit cyclomatic complexity to 10 or provide
a written explanation of why the limit was exceeded.”

Solve control flow graph with complexity 17.

9.1.4 Examples of Cyclomatic Complexity
Independence of complexity and size

There is a big difference between complexity and size. Consider the difference between the
cyclomatic complexity measure and the number of lines of code, a common size measure. Just

LOVELY PROFESSIONAL UNIVERSITY 183