What is McCabe Code Complexity?

McCabe code complexity, also called cyclomatic complexity, is a software metric that counts the number of independent execution paths through a piece of code. Thomas McCabe introduced it in 1976, and it remains one of the most widely used quantitative measures of code structure and maintainability.

The metric lives at the function or method level. Every branch point in your code, an if, a loop, a case statement, adds to the count. A function with no branches scores a 1. A function handling ten conditions and loops could score 15 or higher.

The thresholds matter: a score of 1 to 10 signals low complexity and is generally safe to maintain. Scores of 11 to 20 indicate moderate complexity and warrant attention during code review. Anything above 20 is high complexity and is reliably associated with higher defect density and testing cost. Research from the original McCabe paper and subsequent validation studies confirms that functions above complexity 10 break down at a statistically significant rate

How to Measure McCabe Code Complexity

The formula is straightforward:

Cyclomatic Complexity = E - N + 2P

E is the number of edges in the control flow graph, N is the number of nodes, and P is the number of connected components (typically 1 for a single function). In practice, most static analysis tools compute this directly from source code without you ever drawing the graph: count the number of branch points in the function and add 1.

Data sources are static analysis tools such as SonarQube, Lizard, Radon (Python), ESLint complexity rules (JavaScript), or language-specific linters. The metric is computed at build time and can be gated in CI pipelines to block merges above a threshold.

Why McCabe Code Complexity Matters for Engineering Teams

High complexity predicts bugs before they ship. A function with a cyclomatic complexity above 20 requires testing for every independent path to achieve full branch coverage. Most teams never get there. The result is untested paths that surface as production incidents later.

For engineering leaders, the metric is useful at two levels. At the function level, it flags specific work for refactoring in the current sprint. At the repository level, tracked over time, it signals whether code health is improving or eroding as features are added at speed.

Platforms like Hivel surface McCabe complexity alongside rework rate and PR cycle time so engineering leaders can see whether code quality is moving in the right direction at system level, not just function by function.

See how Hivel tracks code complexity across your engineering org →