What is cyclomatic complexity?
Updated
Cyclomatic complexity is a metric, introduced by Thomas McCabe in 1976, that counts the number of linearly independent paths through a piece of code — usually a single function or method. Each branch point (an if, a loop, a case, a boolean operator) adds a path, so a function with many decisions has a high score and a straight-line function scores one.
The metric matters because independent paths are what tests must cover and what a reader must hold in their head. High cyclomatic complexity means a function is harder to test exhaustively, harder to understand, and statistically more likely to contain defects. It is a useful early signal of code that may need refactoring — but a signal, not a rule.
How cyclomatic complexity is calculated
The most practical way to compute it is to count the decision points in a function and add one. Every if, else-if, for, while, case, and short-circuiting boolean operator (&& or ||) introduces a branch and increments the count; the plus-one accounts for the single path through a function with no branches. A function that is a straight sequence of statements has a cyclomatic complexity of one.
The number has a direct testing interpretation: it is a lower bound on the number of test cases needed to exercise every independent path through the function at least once. That is why the metric is often used to flag functions that are under-tested relative to their branching — a complexity of fifteen with three tests is a visible gap.
What it signals — and where it misleads
As a rough guide, low single-digit complexity is easy to follow and test; scores climbing into the teens and beyond mark functions that are hard to reason about and are candidates for being broken into smaller pieces. Tracking complexity over time, and at the function level, helps a team catch methods that are quietly accreting branches before they become unmaintainable.
Its limits are important. Cyclomatic complexity counts control-flow branches only — it does not see data complexity, poor naming, hidden coupling, or whether the logic is actually correct. A genuinely complex domain may warrant a high score, and a low score does not mean code is good. Treat it as one input among several (alongside churn, test coverage, and human review), never as a target to be gamed by, say, hiding branches in helper functions.
Frequently asked questions
How do you calculate cyclomatic complexity?
Count the decision points in a function — each if, else-if, loop, case, and short-circuiting boolean operator — and add one. The plus-one accounts for the single path through a branch-free function. The result equals the number of linearly independent paths through the code and is a lower bound on the tests needed to cover them all.
What is a good cyclomatic complexity score?
Low single digits are easy to follow and test; scores rising into the teens and beyond flag functions worth simplifying. There is no universal hard limit — a genuinely complex domain can justify a higher score — so the metric is best read as a per-function signal and a trend, not a pass/fail threshold.
What are the limits of cyclomatic complexity?
It measures control-flow branching only. It cannot see data complexity, naming, coupling, or whether the code is correct, and a low score does not imply good code. It is also gameable by splitting logic across helper functions. Use it alongside test coverage, code churn, and human review rather than as a standalone verdict.
Published by ShipReady Metrics, an evidence-based technology and compliance intelligence platform. This guide is educational and vendor-neutral.