Paste code and get McCabe cyclomatic complexity per function, with every decision point shown by line number and checked against published limits.
Nothing is uploaded — the counting runs in your browser.
Start at 1 and add one per decision. NIST SP 500-235 section 4.1
| Construct | Adds | Why |
|---|---|---|
| if | 1 | One new branch through the code. |
| else if / elif | 1 | Its own decision, tested only when the previous one was false. |
| for, foreach, while, do-while | 1 | The loop condition decides whether the body runs again. |
| case label | 1 | A k-way switch adds one less than its number of outgoing edges, which is one per case label. |
| catch / except | 1 | Each handler is a separate path out of the try block. |
| ternary conditional | 1 | A conditional expression is a decision, exactly like an if. |
| short-circuit AND | 1 | Short-circuit evaluation means the right operand may never run, so it is a branch. |
| short-circuit OR | 1 | Same reason as AND — the right operand is conditional. |
| null-coalescing operator | 1 | The right-hand value is evaluated only when the left is null. |
| null-conditional operator (?.) | 0 | Not counted here. It short-circuits, but it guards a member access rather than choosing between two computations, so an idiomatic a?.b?.c would add three to a function most reviewers would call decision-free. Tools disagree: lizard counts it. Your build analyzer may report a slightly higher number for chains like this. |
| a bare else | 0 | It is the false edge of an if that has already been counted. |
| a switch default | 0 | It is the switch's fall-through edge, already accounted for by the case labels. |
| the switch keyword itself | 0 | The switch is not the decision; its case labels are. |
| a return statement | 0 | Exit points do not change cyclomatic complexity. Ten returns or one, the count is the same. |
The thresholds real standards and tools actually specify
| Source | Limit | Applies to |
|---|---|---|
| McCabe 1976 / NIST SP 500-235 section 2.5 | 10 | Per module. The section is titled Limiting cyclomatic complexity to 10. |
| NIST SP 500-235, upper allowance | 15 | Only for projects with experienced staff, formal design, structured programming and a comprehensive test plan. |
| NASA NPR 7150.2 section 3.7.5 (SWE-220) | 15 | Safety-critical components. Any exceedance must be reviewed and waived with rationale. |
| SonarQube rule S1541, default parameter | 10 | Per method. Note the rule is not enabled in SonarQube's default profile. |
| ESLint complexity rule, default | 20 | Per function. Note the rule is off unless you turn it on. |
Counting is lexical, not a full parse: strings and comments are ignored, but unusual macros, generated code or a syntactically incomplete snippet can shift the count. Treat the result as a review aid, and use your build's own analyzer as the number of record.
You might also find these calculators useful
Paste code, get its time and space Big-O with the derivation
Coverage by criterion, checked against requirements we can cite
Count SLOC, comments and blanks from pasted code, then estimate effort
Measure DevOps performance with four key metrics
Paste a function or a whole file and this calculator counts its decision points for you, reports the cyclomatic complexity of every function it finds, and shows you the line each decision was counted on. It reads Python, JavaScript, TypeScript, Java, C, C++, C# and Go, and the counting runs entirely in your browser. If you would rather work from a control-flow graph or a count you already have, both of those modes are here too.
Cyclomatic complexity, introduced by Thomas J. McCabe in 1976, counts the linearly independent paths through a module. A straight-line function has a complexity of 1; every decision adds one. The number matters for two practical reasons: it is exactly the number of tests a basis-path test suite needs, and it correlates with how hard the code is to read and change. Counting decision points and reading the numbers off a control-flow graph are two routes to the same answer.
McCabe's Formula
Paste the function under review and get a number plus the line-by-line reason for it, which turns a subjective argument about complexity into a checkable count.
Use the complexity of each function as the exact size of its basis-path test set, and as the ceiling on how many tests full branch coverage will need.
Before turning on a complexity gate, run your worst files through this and see what a limit of 10, 15 or 20 would reject, so the threshold you pick is one the team can actually meet.
NASA NPR 7150.2 requires safety-critical components to sit at 15 or lower, with any exceedance waived in writing. Measure per function to see which components need that rationale.
The complexity number is exactly how many tests a basis-path suite needs, and an upper bound on how many full branch coverage needs — NIST SP 500-235 notes that covering every edge can usually be done with fewer paths. Knowing which bound applies stops you over-scoping a test plan.
A file-level average hides the problem. This calculator reports every function separately and sorts them worst first, so the one function carrying the complexity is the first row rather than a number you have to hunt for.
Limits get repeated without provenance. Every threshold here names a document: McCabe's original 10, the 15 NIST allows under stated conditions, NASA's 15 for safety-critical code, SonarQube's and ESLint's rule defaults.
CI thresholds only work if the number they act on is the worst function, not a file total. Seeing the per-function breakdown tells you what a gate at 10 or 15 would actually reject today.
Exactly 10 for basis-path testing — NIST SP 500-235 states that the number of test paths required for a module is exactly its cyclomatic complexity. For branch coverage it is an upper bound, not a minimum: NIST section 2.4 shows a module of complexity 3 whose edges are all covered by 2 of the 3 basis paths, and notes that covering all edges can usually be accomplished with fewer paths. For full path coverage the complexity is a lower bound, and a loop can make the true number unbounded.
No. A function with ten returns and a function with one have the same cyclomatic complexity if they make the same decisions. A control-flow graph with s exit points needs s virtual edges to become strongly connected, so v = E + s - N + 1, and substituting E = N - s + π gives π + 1 for any s. NIST SP 500-235 states v(G) = π + 1 with no exit-point term anywhere in its 124 pages, and reference analyzers agree. You may see M = π - s + 2 quoted for multiple-exit programs; it assumes a different graph convention and does not match what production tools report.
Each if, else if or elif, for, foreach, while, do-while, case label, catch or except, ternary conditional, and each short-circuit &&, || or ?? operator. Start at one and add one for each. A bare else adds nothing, because it is the false edge of an if already counted, and a switch default adds nothing for the same reason.
Because short-circuit evaluation makes each operand a branch. In if (a && b) the test of b runs only when a is true, so there are three paths through the statement, not two. This is why refactoring a long boolean expression into a named helper genuinely reduces the measured complexity of the function it came from.
Per function. Cyclomatic complexity is defined for a single module with one entry point, and every published limit is stated per method or per function. A file total tells you how much branching a file contains, which is useful for triage, but it is not the number any standard applies. This calculator reports both and defaults the headline to the worst function.
No. Cyclomatic complexity counts paths and treats every decision as equal. Cognitive complexity, which SonarQube's default profile uses instead, weights nested decisions more heavily and ignores some structures that add paths but not confusion, such as a long switch. They answer different questions: cyclomatic tells you how many tests you owe, cognitive estimates how hard the code is to read.
Ten is the defensible default. NIST SP 500-235 titles its section Limiting cyclomatic complexity to 10 and says the original limit has significant supporting evidence, while noting that limits as high as 15 have been used successfully by projects with experienced staff, formal design, structured programming and a comprehensive test plan. NASA caps safety-critical components at 15 with written waivers. SonarQube's rule defaults to 10 and ESLint's to 20.
Extract each compound condition into a well-named predicate function, replace nested conditionals with early-return guard clauses, move a long switch onto polymorphism or a lookup table, and split any function doing two jobs into two functions. Note that adding returns does not help and removing them does not hurt: only removing decisions lowers the number.