Paste any code snippet to get a rough, heuristic read on its cyclomatic complexity, nesting depth, comment ratio, and overall maintainability — a quick gut-check, not a substitute for a real static analysis tool.
Paste a code snippet to see its complexity estimate
The code complexity calculator gives you a rough, at-a-glance read on how complex and maintainable a code snippet is — without installing a linter, configuring a static analysis tool, or even knowing what language you're looking at. Paste in any snippet and it immediately estimates cyclomatic complexity, maximum nesting depth, comment coverage, and average line length using simple text-pattern heuristics, then combines complexity and nesting into a single Simple / Moderate / Complex / Very Complex maintainability rating. It's built for quick sanity checks — skimming a pull request, deciding whether a function needs refactoring, or getting a fast second opinion before diving into a proper code review — not as a replacement for real static analysis tooling.
Lines of code are counted by splitting the snippet on line breaks and discarding blank lines; comment lines are identified by checking whether a trimmed line starts with a common comment marker (//, #, /*, *, or --), and the comment ratio is comments ÷ non-blank lines. Cyclomatic complexity starts at 1 (representing a single straight-line path through the code) and adds 1 for every occurrence of a decision-point keyword or operator — if (which also naturally covers every else if), for, while, case, catch, elif, &&, ||, and the ternary ?: operator — found via word-boundary regex matches across the whole snippet. Nesting depth is estimated by measuring each line's leading whitespace (tabs expanded to spaces), detecting the most common indentation step, and dividing the deepest indentation found by that step size.
Five numbers come out of the analysis. Lines of code and comment ratio describe the shape of the snippet; cyclomatic complexity counts independent decision paths; max nesting depth captures how many levels of control structure are stacked; and average line length is a secondary readability signal. The maintainability rating folds complexity and nesting together into one bucket so you can act on the result without reading a metrics dashboard.
It's for developers skimming a pull request, reviewers who want a quick second opinion before asking for changes, engineering managers measuring technical debt, and QA engineers planning test coverage. It's equally useful for students learning why complexity and nesting matter, since it makes the effect of every if and for visible rather than buried in a tool report.
Every additional decision point roughly doubles the number of distinct paths a reviewer or test suite needs to cover, and deep nesting makes those paths harder to read and easier to misread. A quick heuristic score like this one can't replace a real code review, but it's a fast, zero-setup way to flag a function that has grown too tangled and might be worth breaking into smaller pieces before it becomes a maintenance burden.
How this code complexity calculator turns a snippet into a numeric score
This estimator uses the decision-point counting form: it starts at 1 for the single linear path and adds 1 for each decision point found via word-boundary regex matches across the whole snippet. Because it matches text rather than building a control-flow graph, keywords inside strings or comments can add to the count.
Counts independent decision paths through code. Lower is simpler to test and reason about; functions above ~10 are commonly flagged as candidates for refactoring in real static analysis tools.
How many levels of indentation (if-inside-if-inside-loop, etc.) a snippet reaches. Deep nesting makes code harder to follow and is often a sign that logic should be extracted into separate functions.
The share of lines that are comments versus code. Useful as a rough documentation signal, though quality matters more than quantity — a few clear comments beat many redundant ones.
From pasting a snippet to acting on your maintainability rating
Enter any code in the text area, in any language. The analysis runs entirely in your browser, so nothing you paste is uploaded or stored.
The results panel updates on every keystroke: lines of code, comment ratio, cyclomatic complexity, average line length, max nesting depth, and detected indent width.
This number starts at 1 and adds 1 for each decision point — if, for, while, case, catch, elif, &&, ||, and the ternary operator. Compare it against the 1–10, 11–20, 21–50, and 50+ ranges in the interpretation section below.
Look at how deep the indentation goes and the indent width the tool detected. A high depth relative to complexity usually means logic should be flattened into helper functions.
Use these as secondary readability signals — a very low comment ratio may indicate unclear code, while very long lines suggest formatting cleanup.
Simple and Moderate are usually fine to merge; Complex and Very Complex are candidates for refactoring. Confirm with a real analyzer like ESLint or radon before rewriting.
Using the calculator's own default sample — a 23-line processOrders function
Paste the default sample processOrders(orders) function into the calculator. It contains two loops, five if/else if branches, two && operators, and one comment line, indented with two-space steps.
Explanation: The sample shows a classic split between a moderate decision count and deep nesting. M = 10 sits right at the common "consider refactoring above 10" threshold, but the real problem is nesting depth 6 — discount logic nested inside bulk-order logic inside status checks. That depth pushes the rating past the Moderate bucket into Complex even though the raw decision count is moderate. A reviewer would reasonably suggest extracting the discount and bulk-order branches into helper functions to flatten the nesting, which would drop the depth even if the decision count stays similar.
What a cyclomatic complexity score generally implies for testability and maintenance
| Cyclomatic Complexity | What It Generally Means | Recommended Next Step |
|---|---|---|
| 1 – 10 | Simple code with few decision paths | Straightforward to test; no action needed |
| 11 – 20 | Moderate — more paths, harder to cover every branch | Test the risky branches; consider refactoring the worst functions |
| 21 – 50 | Complex — high bug risk and difficult to modify safely | Refactor before adding features; split into smaller functions |
| 50+ | Untestable in practice — too many paths for reasonable coverage | Plan a rewrite or decomposition; schedule a dedicated refactor |
If complexity is low but nesting is deep: the code may still be hard to follow even though it has few decision paths. Deeply nested logic is a readability problem that extraction and early returns solve, so don't stop at the complexity number alone.
If the score is borderline: treat the threshold the same way you would a lint rule — as a default to override deliberately. A score of 12 in a parser or a state machine may be perfectly reasonable, while a score of 8 in a hot loop with deep nesting may still need cleanup.
These are heuristic estimates based on text patterns, not exact values from an abstract syntax tree. Confirm any borderline function with a real analyzer before making changes.
This calculator provides a heuristic estimate only. It does not parse code and cannot model language semantics, real control flow, or scope. Use the rating as a triage signal, then validate with a proper static analysis tool appropriate to your language before deciding to refactor.
Where estimating complexity and nesting depth genuinely helps
Flag functions that have grown too tangled during review, before they merge and become someone else's problem.
Rank functions by complexity and depth so the riskiest code gets refactored first and the effort is visible.
Estimate how many decision paths a function has to plan branch tests and predict where coverage will be hardest.
Measure legacy code before a modernization or migration effort to quantify how tangled the cleanup will be.
Get a quick second opinion on your own diff before defending a change in review against complexity concerns.
Show students how adding an if or a nested loop visibly changes the score, making McCabe's metric concrete.
Compare two candidate implementations of the same feature side by side and pick the less tangled one.
Enforce an informal "keep cyclomatic complexity below 10" rule on a small team without heavy tooling.
Check that a coding-exercise solution isn't over-complex, which is a strong signal of poor design.
Get a rough complexity read on code in a language you don't know well, using only generic text patterns.
Produce a first complexity estimate before integrating a real analyzer into the build pipeline.
Re-measure after extracting functions to confirm complexity and nesting depth actually dropped.
What this code complexity calculator does well, and where it can't replace a real analyzer
How the main code-complexity metrics differ and when each one matters
| Metric | What It Measures | Best For | Key Limitation |
|---|---|---|---|
| Cyclomatic Complexity | Independent decision paths (M = E − N + 2P) | Testability and path-coverage planning | Counts every branch equally regardless of readability |
| Cognitive Complexity | How hard the flow is for a human to follow; weights nesting and breaks in linear flow | Readability scoring and refactoring priority | Less formally standardized than McCabe's metric |
| Nesting Depth | Levels of indentation / nested control structures | Spotting deeply nested logic worth extracting | Depends on consistent indentation style |
Summary: This code complexity calculator gives you an instant, free estimate of cyclomatic complexity, nesting depth, comment ratio, and line length — with a combined Simple-to-Very-Complex maintainability rating — so you can triage code before a review and plan refactoring with real numbers instead of guesswork. Pair it with the Regex Tester and API Rate Limit Calculator for a fuller developer-toolbox review of a service.
Common questions about this code complexity calculator and its metrics
The original paper, standards, and tooling documentation that define these metrics
Explore other developer & tech tools