Code Complexity Estimator

Cyclomatic complexity counts paths

Developed by Thomas McCabe in 1976, it counts linearly independent paths through a function. In practice it is one plus the number of decision points: each if, each loop, each case, each catch, and each logical operator that short-circuits. A function with no branches scores 1. The number is also the minimum count of test cases needed for full branch coverage, which is its most concrete practical use.

What the ranges mean

1 to 10 is simple and straightforward to test. 11 to 20 is moderate and warrants a look. 21 to 50 is complex, hard to test thoroughly and a frequent source of defects. Above 50 is generally considered untestable. These bands are conventions rather than laws, and the underlying claim — that defect density rises with complexity — holds in aggregate but not for every individual function.

Cognitive complexity measures something different

Cyclomatic complexity treats a flat switch with twenty cases the same as four levels of nested conditionals, though one is trivial to read and the other is not. Cognitive complexity, introduced by SonarSource, penalises nesting and rewards structures humans follow easily. It correlates better with how hard code is to understand, which is usually the actual question. Where the two disagree, cognitive complexity is generally the more useful signal.

The metric is easy to game

Extracting half a long function into a private helper halves the reported complexity while changing nothing about the logic. If a threshold is enforced as a build gate, this is what teams do, and the codebase acquires helpers that exist purely to satisfy a linter. Complexity is a prompt to look, not a target to hit.

Where high complexity is legitimate

Parsers, state machines, validators and protocol implementations have genuinely many branches because the domain does. Splitting a coherent state machine into fragments to satisfy a threshold makes it harder to follow, not easier. The question is always whether the complexity is inherent in the problem or accidental in the solution.

Use it to prioritise, not to judge

The productive use is intersecting complexity with change frequency. A complex function nobody has touched in three years is stable and can be left alone. A complex function modified fifteen times this quarter is where defects will appear and where refactoring pays. Complexity alone ranks nothing useful; complexity crossed with churn ranks the actual risk.