Understanding Cyclomatic Complexity and How to Apply Excessive Cyclomatic Complexity

In the previous article we discussed the metric "cyclomatic complexity". Many developers are unfamiliar with its precise definition despite its decades‑long history.

To understand cyclomatic complexity, one must first know the McCabe metric. The McCabe metric transforms a program's flowchart into a directed graph and uses graph‑theoretic methods to assess software quality. It includes cyclomatic complexity, basic complexity, module complexity, design complexity, and integration complexity. Control flow graph analysis is a static analysis technique mainly used in white‑box testing, and the control flow graph is the basis for McCabe complexity calculation.

An important property of a control flow graph is its reducibility. If a program contains no goto statements that jump from outside a loop to inside the loop, the graph is reducible; otherwise it is irreducible. Therefore, adhering to structured programming principles ensures a reducible control flow graph.

2. Cyclomatic Complexity

Cyclomatic complexity, often denoted V(G), measures the number of linearly independent paths through a program module. It reflects the number of decision points and thus the minimum number of test paths needed to achieve reasonable error detection. Empirical evidence shows a strong correlation between higher cyclomatic complexity and a greater number of bugs.

The calculation is simple: V(G) = e - n + 2 , where e is the number of edges and n is the number of nodes in the control flow graph. An equivalent view is that cyclomatic complexity equals the number of decision nodes plus one, i.e., the number of regions in the graph.

When counting decision nodes for multi‑branch CASE or IF‑ELSEIF‑ELSE structures, every ELSEIF and every CASE clause must be counted as a separate decision node. For program‑level graphs the first formula ( V(G)=e-n+2 ) is recommended; for module‑level graphs counting decision nodes directly is often simpler.

In plain terms, cyclomatic complexity tells you how many distinct execution paths exist in your code.

3. Proper Use of Cyclomatic Complexity

Many analysis tools report an "average cyclomatic complexity" as an overall quality indicator. This is misleading because a software system typically contains many low‑complexity functions and a few high‑complexity ones, and most defects arise in the latter. Averaging masks the risk.

Instead, the article proposes using "excessive cyclomatic complexity" to gauge software complexity.

4. What Is Excessive Cyclomatic Complexity?

Excessive cyclomatic complexity is the sum of the amounts by which individual functions exceed a predefined threshold. For example, with a threshold of 20 for Java methods, functions with complexities 27 and 25 exceed the limit by 7 and 5 respectively, giving an excessive cyclomatic complexity of 12.

5. How to Use Excessive Cyclomatic Complexity

Apply the "Scout Camp Principle": before each code commit, compute the repository's excessive cyclomatic complexity. If the new value is higher than the previous one, reject the commit. This helps ensure code quality does not degrade over time.

By following this practice, the codebase is prevented from becoming worse.