Cyclomatic Complexity - McCabe M from E, N, P

Cyclomatic complexity is a software-metric score that counts how many linearly independent paths a program has. A cyclomatic complexity calculator applies Thomas J. McCabe's 1976 formula M = E - N + 2P to the control-flow graph, where E is edges, N is nodes, and P is connected components. Higher M means more branches, loops, and unusual exits, and therefore more test cases and more code-review attention.

• • Scoring a single function before code review: Plug in edges, nodes, and connected components from a function's control-flow graph and quickly see whether the function clears the McCabe threshold of 10.
• • Planning a test suite: Use the recommended minimum test count (which equals M for a single function) as a target for branch coverage. Each independent path is one test case you should write.
• • Comparing two refactors: Score the original and refactored function the same way. If M drops, the refactor simplified the control flow even if lines of code did not change.
• • Auditing an unfamiliar codebase: Spot the worst offenders in a large module by scoring each function and sorting the results. Functions with M well above 10 are the natural place to start.

M matters because it sits at the intersection of three things developers care about: how hard the code is to read, how many test cases are needed to cover it, and how likely a refactor is to introduce regressions. A function with M = 1 is a straight line of code; a function with M = 25 is a maze of branches.

Because M comes from a small graph-theoretic formula, the score is reproducible: two engineers who draw the control-flow graph the same way will get the same number, which is why this kind of tool is useful rather than a stylistic opinion.

When you want to see the shape of a polynomial alongside the algebraic formula, the polynomial graphing calculator plots the curve and lists the key turning points.

The calculator takes the three integers E, N, and P that you read off the control-flow graph, runs them through McCabe's formula, and returns M together with a recommended test count and a complexity band. Everything else on the page is just a label or a guideline that helps you act on the number.

• E: Number of directed edges in the control-flow graph. Each jump, branch, or fall-through counts as one edge.
• N: Number of nodes in the reduced control-flow graph. Sequential statements get merged so each node is a meaningful decision or step.
• P: Number of connected components. A single function has P = 1; P grows when subprograms or unconnected code regions exist.
• M: The McCabe number, equal to the number of linearly independent paths in the code.

The formula is closed form, so the calculator does not need a graph library or a parser. You read the counts off the graph and type them in; the rest is arithmetic. Most modern code-quality tools (SonarQube, CodeScene, NDepend) still use this approach.

According to Wikipedia, 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 the program's control-flow graph.

According to Omni Calculator, a Collatz conjecture program with 14 nodes, 18 edges, and a single connected component has M = 18 - 14 + 2*1 = 6.

If you would rather solve the underlying equation symbolically than count branches in a graph, the quadratic formula calculator handles the standard ax^2 + bx + c case directly.

These four ideas cover the building blocks you need before you start counting nodes and edges. If you can read a control-flow graph and recognize a connected component, the rest of the metric follows.

These four ideas are enough to read M off any control-flow graph. Edges and nodes are the raw counts, connected components fix the scale, and independent paths explain why M doubles as a test count.

Graph-style math that involves roots and branches of the complex plane shows up often in flow-graph theory, and the complex number calculator is a useful companion for those sub-problems.

The workflow is short: draw the control-flow graph, count the edges and nodes, plug them in, and read the result.

1. 1 Draw the control-flow graph: Map each statement or decision to a node and each jump or branch to a directed edge. Merge sequential nodes that have a single predecessor and a single successor so the graph only shows decisions.
2. 2 Count the edges (E): Count the arrows in the graph. Every if, for, while, switch, and break adds at least one edge beyond the fall-through arrow.
3. 3 Count the nodes (N): Count the boxes in the reduced graph. Sequential statements that you merged in step 1 count as one node, not several.
4. 4 Set the components (P): Use P = 1 for a single function. Increase P by 1 for every separate function or unreachable region you include in the score.
5. 5 Type the values into the form: Enter E, N, and P into the three number fields. The result panel updates as you type.
6. 6 Read M, the test count, and the band: M is the McCabe number, the recommended minimum tests equals M, and the band tells you whether the function is simple, moderate, complex, or high risk.

For 'if (n > 0) return 1; else return -1;' the reduced graph has 4 nodes and 4 edges, and a single function has P = 1. Type E = 4, N = 4, P = 1. The calculator returns M = 2, two recommended tests, and a simple band.

Counting permutations and combinations for test-path enumeration is a common side task, and the factorial calculator gives you n! and related values without rebuilding the formula.

Counting M by hand is possible for a tiny function, but the arithmetic and the band classification are exactly the things a calculator should do for you. Here is what you get out of using it.

• • Whole-number M with no manual math: Type E, N, and P, and M comes back as a whole number with no manual arithmetic or rounding decisions.
• • Recommended test count: The output panel shows the minimum test cases needed for branch coverage, which equals M for a single function. Use it as a target when you plan a test suite.
• • Complexity band label: A plain-English band (simple, moderate, complex, high risk) maps M onto the McCabe and SonarSource thresholds so non-specialists can read the score. Simple is M = 1-4, moderate is M = 5-10, complex is M = 11-20, and high risk is M above 20.
• • Reproducible across reviewers: Two engineers who count the same control-flow graph will get the same M, which removes the 'how complex is too complex' debate from code review.
• • Works for any language: The formula is graph-theoretic, not language-specific. Use the same numbers for C, Python, JavaScript, or pseudocode as long as you can draw the control-flow graph.

These benefits line up with the way modern code-quality tools report M in continuous integration. A static score, a band, and a test count are the three pieces of information you actually need to act on.

Adjacency-style representations of a control-flow graph line up with matrix work, and the adjoint matrix calculator is the right tool when you need the cofactor matrix behind the same kind of graph math.

Four inputs change the answer the calculator returns, and the limitations below cover what the McCabe formula does not capture on its own.

• • M is a structural metric, not a readability score. A function with M = 3 can still be hard to read if it uses obscure names or deeply nested expressions.
• • M does not capture data flow or coupling. A function that mutates a global variable in three different branches has the same score as one that does not.
• • M is a property of one control-flow graph. The calculator cannot tell you which function in a 1,000-line module deserves the most attention; you still have to score each function separately.

These factors and limitations are why most teams treat this kind of calculator as one signal among several. Pair M with a coverage report and a code-review pass, and you get a much fuller picture of test risk than any single metric can offer.

According to SonarSource, the original McCabe threshold of M = 10 for breaking a module apart is widely cited, but modern code-quality tools such as SonarQube typically default to lower thresholds when scoring M in code review.

If you are scoring example programs that include prime checks, the prime number checker confirms which integers trigger the worst-case branch in your function.