Cyclomatic Complexity
Cyclomatic Complexity Metric · Also known as: CC, cyclomatic number, McCabe complexity
Cyclomatic Complexity (CC), introduced by Thomas McCabe in 1976, is a quantitative metric measuring the number of linearly independent paths through a function's control-flow graph. A function with high cyclomatic complexity is harder to understand, test, and maintain; McCabe advocated a threshold of 10 as the complexity limit for maintainability.
Read the full method
Sign in with a free account to read this section.
Method map
The neighbourhood of related methods — select a node to explore.
When to use it
Use cyclomatic complexity to identify functions needing refactoring, estimate test effort, and set quality gates. Essential for safety-critical systems (aerospace, medical) where high coverage is mandatory. Combine with other metrics (code duplication, size) for holistic quality assessment. Less useful for data processing code with minimal branching.
Strengths & limitations
- Simple to compute: tools (ESLint, SonarQube) calculate automatically for all languages
- Strongly correlates with testing effort: empirically validated by decades of use
- Actionable: exceeding threshold clearly indicates need for refactoring (break into smaller functions)
- Language-independent: same metric applies to C, Python, Java, JavaScript, etc.
- Only measures branching, ignores data-flow complexity (nested loops with complex invariants still have low CC)
- Doesn't distinguish between equal and nested conditions: serial if statements same CC as nested if-else
- Misleading for languages with implicit complexity (exceptions, callbacks, concurrency) not shown in control flow
- Threshold 10 is arbitrary; McCabe's original justification (cognitive limits) is debated
Frequently asked
Is cyclomatic complexity the same as the number of decision points?
Almost: CC = (decision points) + 1. A function with no branches (CC = 1) has 0 decision points. Each if, while, case adds one decision point; logical operators (&& and ||) can add points depending on how tools count them.
How do I reduce cyclomatic complexity in a function?
Extract branches into helper functions: each extracted function starts with CC = 1. Use polymorphism to replace switch statements (strategy pattern). Use guard clauses (early returns) to flatten nesting. Consolidate conditions with && and || carefully.
Should I worry about CC in lambdas and short callbacks?
Not as much: lambdas are typically simple. Focus on functions > 20 lines or main logic paths. Tools may report high CC for callbacks, but they're often not the bottleneck for testing effort.
How does CC relate to testing effort (number of test cases)?
CC is the minimum number of tests for 100% path coverage. CC = 4 requires at least 4 tests. In practice, boundary value analysis and error cases add more, but CC gives a lower bound on necessary tests.
Sources
- McCabe, T. J. (1976). A complexity measure. IEEE Transactions on Software Engineering, SE-2(4), 308–320. DOI: 10.1109/TSE.1976.233837 ↗
- Campbell, G. H. (1986). Defining a good metric, a software testing perspective. ASQ Software Quality Conference. link ↗
- Nagy, C., & Kriebel, K. (2001). Achieving optimal complexity and reliability. SAMS Publishing. ISBN: 0672322285
How to cite this page
ScholarGate. (2026, June 3). Cyclomatic Complexity Metric. ScholarGate. https://scholargate.app/en/numerical-methods/cyclomatic-complexity
Which method?
Set this method beside its closest kin and read them side by side — the library lays the books on the table; the choice is yours.
- Halstead ComplexityNumerical Methods↔ compare