Cyclomatic Complexity
This metric tracks the complexity of software based on the number of linearly independent paths through the source code.
Main Description

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