Cyclomatic Complexity Calculator

Last updated October 4, 2026 · Report an error

Thanks for rating!

McCabe's cyclomatic complexity, introduced by Thomas McCabe in 1976, measures the number of linearly independent paths through a program's control-flow graph — a graph where each node represents a straight-line block of code with no branching, and each edge represents a possible jump from one block to the next (an if statement, loop, or switch case, for example). It's one of the oldest and still most widely used software complexity metrics, because it correlates closely with how many distinct test cases are needed to exercise every possible branch in a function at least once. Development teams use cyclomatic complexity as an automated code-quality gate: many static analysis tools flag any function scoring above a threshold (commonly 10) as a candidate for refactoring, since high complexity scores are strongly associated with more bugs, harder debugging, and higher long-term maintenance cost. It's also used directly to size a minimal test suite — the metric itself equals the minimum number of test cases needed to achieve full branch coverage of the function.

How it works

Enter the number of edges (E, the possible control-flow transitions between blocks) and nodes (N, the blocks of straight-line code) in the control-flow graph, plus the number of connected components (P, which defaults to 1 for a single self-contained function or program). The calculator applies McCabe's formula, M = E − N + 2P. Intuitively, every additional decision point in the code (an if, while, for, case, or similar branching construct) adds both a new edge and a new node to the graph in a way that nets out to increasing M by exactly 1 — which is why cyclomatic complexity is very often computed in practice using the simpler equivalent shortcut, M = (number of decision points) + 1, for a single connected function.

Enter edges (E).
Enter nodes (N).
Enter connected components (P, default 1).
Click Calculate to see your results.

Examples

E = 11, N = 9, P = 1

M = 11 − 9 + 2(1) = 4 — a moderately simple function, likely containing around three decision points (since M = decisions + 1 for a single component).

E = 15, N = 10, P = 1

M = 15 − 10 + 2(1) = 7 — approaching the commonly cited threshold of 10, at which many teams flag a function as due for refactoring or splitting into smaller pieces.

E = 20, N = 15, P = 2 (two disconnected functions analyzed together)

M = 20 − 15 + 2(2) = 9 — note the "+2P" term adds 2 for each additional disconnected component, since every separate function or subgraph contributes its own baseline path.

Common mistakes to avoid

Forgetting to change P from its default of 1 when the graph actually represents multiple disconnected components rather than a single function.
Miscounting nodes or edges by treating a compound condition (like "if (a && b)") as a single decision point instead of the two separate branches it actually introduces.
Assuming cyclomatic complexity measures overall code length or readability — it specifically measures branching complexity, and a long function with no branches at all can still have a complexity of 1.
Using the raw M = E − N + 2P formula on a large, unfamiliar codebase without first double-checking node and edge counts — small counting errors compound quickly in bigger graphs.

Frequently asked questions

Nodes are basic blocks — straight-line sequences of code with no branches in or out except at the very start and end. Edges are the possible control-flow transitions between those blocks, such as the two branches created by an if/else statement or the loop-back edge created by a while loop.

When analyzing a single function or program, P is almost always 1. It only needs to increase if you're deliberately analyzing multiple independent, unconnected functions together as one combined graph, which is a less common use case than analyzing one function at a time.

Common industry guidance treats 1–10 as simple and low-risk, 11–20 as moderately complex and worth reviewing, 21–50 as complex and high-risk, and above 50 as very high risk and difficult to test thoroughly — though these thresholds vary somewhat by organization and codebase.

Yes — for a single function, M equals the number of decision points (if, else if, while, for, case, &&, ||, catch, and similar branching constructs) plus 1, which avoids manually counting nodes and edges and is how most static analysis tools compute the metric in practice.

Not necessarily on its own — some genuinely complex problems require correspondingly complex logic — but a high score reliably signals that a function has many distinct execution paths, which does correlate strongly with higher testing effort and higher defect rates in empirical software engineering studies.

The metric directly equals the minimum number of independent test cases needed to exercise every edge in the control-flow graph at least once — so a function with a cyclomatic complexity of 7 needs at least 7 well-chosen test cases to achieve full branch coverage.

Free Cyclomatic Complexity Calculator