Cyclomatic Complexity Calculator
Enter your control-flow graph values or simply count the decision points in your code. The calculator applies McCabe's formula to produce the cyclomatic complexity, classify the result against the standard four-band risk scale, and estimate the minimum number of test cases needed for full branch coverage.
What is cyclomatic complexity?
Cyclomatic complexity is a software metric introduced by Thomas J. McCabe in 1976 to quantify the logical complexity of a program. It counts the number of linearly independent paths through a piece of code, which is equivalent to the number of binary decisions (branches) plus one. A function with no conditionals at all has a complexity of 1, meaning there is exactly one path through it. Each if, else if, for, while, do-while, case, catch, logical AND (&&), logical OR (||), or ternary operator adds one to that count.
How to calculate cyclomatic complexity
There are two equivalent ways to compute the metric. The graph-based method treats the function as a control-flow graph, where each basic block of sequential code is a node and each possible transfer of control is a directed edge. The formula is M = E - N + 2P, where E is the number of edges, N is the number of nodes, and P is the number of connected components (usually 1 for a single function). The decision-based shortcut, often easier in practice, counts every branching construct and adds one: M = D + 1. Both methods always give the same answer for well-formed code.
Risk levels and what they mean for testing
McCabe defined four risk bands that remain the standard in most static analysis tools. Complexity 1-4 indicates a simple module that is easy to unit-test. Complexity 5-7 is moderate; you should ensure tests cover each branch. Complexity 8-10 signals high risk and is a strong hint that the module could be split into smaller, more focused functions. Above 10, the code is typically very hard to test exhaustively; McCabe himself recommended that no module should exceed this threshold. The cyclomatic complexity also tells you the minimum number of test cases required to achieve full branch coverage: you need exactly M tests.
Worked examples
A plain sequential function with no branches has E = 3, N = 4, P = 1 (entry node, one block, exit node, plus edges between them), giving M = 3 - 4 + 2 = 1. A simple if/else statement adds two edges and one extra node compared with the sequential case, producing M = 2. A function with an if inside a for loop typically yields M = 3 or 4 depending on whether the loop condition is counted separately. A complex parser or state machine with ten branches across nested conditions can easily reach M = 15 or higher, signaling a strong refactoring need.
McCabe's cyclomatic complexity risk bands
| Complexity (M) | Risk level | Recommendation |
|---|---|---|
| 1 - 4 | Low | Simple, easy to test. No action needed. |
| 5 - 7 | Moderate | Manageable. Add test coverage for each branch. |
| 8 - 10 | High | Consider refactoring into smaller routines. |
| > 10 | Very high | Refactoring strongly recommended; very difficult to test. |
Published by Thomas J. McCabe in his 1976 IEEE paper. The thresholds are widely adopted in static analysis tools and coding standards.
Frequently asked questions
What does a cyclomatic complexity of 1 mean?
A value of 1 means there is exactly one path through the code, that is, no conditional branches, loops, or logical operators at all. This is the minimum possible value and represents the simplest possible function.
Why does cyclomatic complexity equal the minimum number of test cases?
Each linearly independent path through the code exercises a different combination of branches. To guarantee that every branch has been tested at least once (branch coverage), you need at least one test case per independent path. Because cyclomatic complexity counts exactly those paths, it gives you the lower bound on how many tests are required.
What is the difference between the graph method and the decision method?
They are mathematically equivalent for well-formed code. The graph method (M = E - N + 2P) works from the control-flow graph and is what static analysis tools use internally. The decision method (M = D + 1) is a quick manual shortcut: count every if, else if, for, while, case, catch, &&, || and ternary, then add one. Both always produce the same result for a single function.
At what complexity level should I refactor my code?
McCabe's original recommendation was to refactor any module that reaches M = 10. Many modern coding standards (MISRA, CERT, SonarQube defaults) use the same threshold or lower it to M = 7 or M = 5. A practical rule is: if a function takes more than a few minutes to reason about by reading it, its complexity is too high.
Does cyclomatic complexity apply to all programming languages?
Yes. The metric is language-agnostic because it operates on the control-flow graph, which exists for any imperative or object-oriented language. The same formula works for C, Java, Python, JavaScript, Go, Rust, and others, though the exact keywords that constitute decision points vary slightly by language syntax.
How do I count connected components (P) in the formula?
For a single function or method analyzed in isolation, P is always 1. You only set P greater than 1 if you are analyzing an entire program with multiple disconnected routines at once - for example, two entry points with no shared control flow between them. In most practical use, you can safely leave P = 1.