What is a good cyclomatic complexity score?

1–10 is simple and low risk. 11–20 is moderate complexity. 21–50 is high complexity with elevated testing difficulty. Above 50 is very high risk and should be refactored immediately.

How do I count decision points without drawing a graph?

Count each if, else if, for, while, do-while, case (in switch), catch, and logical operators (&& and ||) in conditional expressions. Add 1 to the total. This gives the same result as the graph formula for a single function.

Does cyclomatic complexity measure code quality?

It measures structural complexity, which correlates with defect density and testing difficulty. However, it doesn't capture domain complexity or code readability. Use it alongside other metrics like cognitive complexity for a complete picture.

What is the relationship between complexity and testing?

The cyclomatic complexity number equals the minimum number of test cases needed for complete path coverage. A function with complexity 10 needs at least 10 tests to cover every independent execution path.

How do I reduce cyclomatic complexity?

Common techniques include extracting methods, replacing conditionals with polymorphism, using lookup tables instead of switch statements, applying the strategy pattern, and breaking large functions into smaller focused ones. Comparing your results against established benchmarks provides valuable context for evaluating whether your figures fall within the expected range.

What is cognitive complexity vs. cyclomatic complexity?

Cognitive complexity (used by SonarQube) measures how hard code is for humans to understand, penalizing nested structures more heavily. Cyclomatic complexity measures the number of paths. Both are valuable but measure different aspects of code complexity.

Cyclomatic Complexity Calculator

Calculate McCabe cyclomatic complexity from edges, nodes, and connected components. Classify code complexity and risk levels.

Edges (E)

Nodes (N)

Connected Components (P)

Language

Number of Methods

Decision Points (if/else/switch)

Cyclomatic Complexity (M)

5.00

M = E(15) - N(12) + 2P(1)

Classification

Very Simple

Very low risk - No refactoring needed

Avg Complexity per Method

1.7

Risk: Very low risk

Minimum Test Cases

5.00

For complete path coverage

Decision Density

50%

6 decisions across 12 nodes

Ideal Code Coverage

100%

Test effort: Low

Maintainability

Excellent

Based on M = 5

Refactoring Priority

None

Under control

Complexity Gauge

1 (Simple)10205060+ (Very Complex)

Component Breakdown

Total Complexity

Per-Method Avg

1.7

Decision Density

Complexity Thresholds Reference

Range	Classification	Risk Level	Min Tests	Action
1-5	Very Simple	Very Low	1-5	None
6-10	Simple	Low	6-10	None
11-20	Moderate	Medium	11-20	Review
21-50	Complex	High	21-50	Refactor
51+	Very Complex	Very High	51+	Rewrite

Planning notes, formulas, and examples

About the Cyclomatic Complexity Calculator

Cyclomatic complexity, introduced by Thomas McCabe in 1976, measures the number of linearly independent paths through a program's source code. It is one of the most widely used software metrics for estimating code complexity, testability, and maintenance risk.

The metric is calculated from the control flow graph of a function: 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. In practice, it equals the number of decision points (if, else, for, while, case) plus one.

This calculator lets you compute cyclomatic complexity and classifies the result into risk categories. Functions with complexity under 10 are simple and easy to test. Those between 11 and 20 are moderately complex. Above 20, the code becomes difficult to understand and test thoroughly.

When This Page Helps

Cyclomatic complexity is the standard metric for identifying functions that are too complex to maintain safely. It gives classification and testing guidance based on the metric value.

How to Use the Inputs

For the graph method: enter the number of edges (E) in the control flow graph.
Enter the number of nodes (N) in the control flow graph.
Enter the number of connected components (P), usually 1 for a single function.
Alternatively, count the decision points in your function and add 1.
Review the complexity score and risk classification.
Use the minimum test cases recommendation for thorough path coverage.

Formula used

M = E − N + 2P
where E = edges, N = nodes, P = connected components

Simplified: M = decision_points + 1
Minimum test cases needed = M

Example Calculation

Result: Complexity = 5 (Simple, low risk)

M = 15 − 12 + 2(1) = 5. A complexity of 5 is classified as simple (1–10 range). The function needs at least 5 test cases for complete path coverage. This is well-structured, maintainable code.

Tips & Best Practices

Keep function complexity under 10 for maintainability; refactor above 15.
Each decision point (if, for, while, case, &&, ||) adds 1 to complexity.
High complexity functions are harder to test — they need more test cases for path coverage.
Use the complexity score to identify refactoring candidates in code reviews.
Guard clauses (early returns) can simplify nested logic without reducing complexity.
Extract complex conditions into well-named boolean functions for clarity.

The McCabe Complexity Metric

Thomas McCabe's cyclomatic complexity has been a cornerstone of software quality measurement since 1976. Its enduring relevance comes from its simplicity and strong correlation with defect rates. Functions with complexity above 10 consistently show 2–3× higher defect density in empirical studies.

Complexity Classification Thresholds

The standard thresholds are: 1–10 (simple, low risk), 11–20 (moderate, medium risk), 21–50 (complex, high risk), and 50+ (untestable, very high risk). These thresholds are widely adopted in static analysis tools and coding standards across the industry.

Practical Application

Integrate complexity checks into your CI/CD pipeline. Set a threshold (typically 10–15) and flag functions that exceed it during code review. This prevents complexity from creeping up over time and keeps the codebase maintainable.

Sources & Methodology

Last updated: February 8, 2026

Frequently Asked Questions

1–10 is simple and low risk. 11–20 is moderate complexity. 21–50 is high complexity with elevated testing difficulty. Above 50 is very high risk and should be refactored immediately.