Purpose
Cyclomatic complexity is an example of static code analysis in which the number of distinct paths through a given code
module is used as a measure of code complexity. High cyclomatic complexity is an indicator of potentially low quality
code that is difficult to test and maintain.
Monitoring code complexity provides several benefits:
-
Can be calculated immediately during development cycles so corrective action can be taken as increased complexity
is introduced. Highlights areas of code that may be difficult to understand, test, and maintain. Helps prioritize
areas of code that need refactoring.
-
Indicator of needed test effort in terms of resources and the number of test cases required for thorough coverage
of the code. Reducing complexity reduces test effort.
-
Helps identify candidate modules requiring team code review
-
Useful input to effort estimations for maintenance
-
Can be used to help determine whether a system should be maintained or redesigned
-
Useful for comparing projects across the organization in terms of quality and maintainability
Definition
Following is a simple method of calculating cyclomatic complexity. It can be computed at the method, class, and package
level.
Cyclomatic Complexity = Number of decision points + 1
Decision points are conditional statements such as Select Case, If...Then, For..Next, While..Wend/ End, and
Catch.
Analysis
The table below provides general guidance for interpreting results
Cyclomatic Complexity
|
Interpretation
|
0-10
|
Simple, low risk
|
11-20
|
Moderately complex, medium risk
|
21-50
|
Complex, high risk
|
50+
|
Highly complex, not testable, very high risk
|
When a particular module has high cyclomatic complexity, confirm associated test coverage to determine the risk of
unidentified defects. Evaluate the need to refactor in order to reduce complexity, creating more testable,
understandable, and maintainable code.
This
metric can also be used to monitor adoption of Test Driven Development and Evolutionary Design practices. Developing
tests before writing code typically results in simple code that is easy to test. Evolutionary design encourages
refactoring providing opportunities to reduce complexity.
Frequency and reporting
Developers can monitor cyclomatic complexity in each development cycle. At the team level, this measurement can be
introduced into daily builds. High complexity code can be reported and flagged for code review.
Collection and reporting tools
Many tools that integrate with developers' integrated development environment are available to automate the process of
calculating cyclomatic complexity. Teams adopting continuous integration practices and tools can include the
measurement in their automated build process, posting results to a dashboard for review during daily meetings and
iteration reviews.
IBM® Rational® Asset Analyzer® reports on this metric.
Pitfalls, advice, and countermeasures
-
There is no direct, consistent relationship between complexity and lines of code.
-
Examine trade-offs (such as performance, unstructured logic) when reducing complexity
-
This metric assumes that all branches have the same weight and impact on complexity, which is typically not the
case. Take this into consideration when monitoring cyclomatic complexity, as well as any complex expressions
associated with a particular branch.
-
When writing a particular test is difficult, it could be an indication that the code under test is overly complex.
-
This metric is also useful for teams of varying skill levels to determine where coaching/ mentoring might be
helpful
|