Code Complexity Analyzer

Measure cyclomatic complexity, lines of code, and maintainability index for JavaScript and TypeScript.

Tested tool guide Tested browser tools Checked August 16, 2026

What Code Complexity Analyzer does, with a checked example

This tool parses a JavaScript or TypeScript snippet or file and reports, per function, its cyclomatic complexity, lines of code, and a maintainability index, so you can see which functions are hardest to test or safest to leave alone before a refactor. Cyclomatic complexity follows the standard model: a baseline of 1 for the function, plus 1 for each additional branch point the parser identifies, such as if and else if conditions and loop conditions, though whether less-common constructs such as case labels, catch blocks, ternaries, and short-circuit && / || operators also count as branch points can vary between analyzers, so treat the number as a relative signal rather than a hand-checkable formula. A function built from many independent sequential checks and a function with the same number of deeply nested checks can land on the same complexity score, since the count tracks total branch points rather than nesting depth.

Worked example

A concrete input and expected output from the current implementation.

Input

function classify(n) {
  if (n < 0) {
    return "negative";
  } else if (n === 0) {
    return "zero";
  } else {
    return "positive";
  }
}

Expected output

classify: cyclomatic complexity 3, lines of code 9

The function has two decision points, the if (n < 0) test and the else if (n === 0) test, each adding 1 to the baseline of 1, giving CC = 3; the plain else adds no path of its own. All 9 physical lines, including the braces, fall inside the function body, giving LOC = 9.

How the result is produced

Branch counting for complexity

Complexity starts at 1 for the function's straight-line path, then adds 1 for each additional branch point such as if, else if, for, and while. Whether less-common constructs - case labels, catch blocks, ternaries, short-circuit && / || - also count as branch points varies by analyzer, so use this score to compare functions within the same analysis rather than as a hand-checkable formula. Lowering the score requires removing an independent branch outright; restructuring the same logic into different syntax, such as a lookup table, only helps if it truly eliminates branch points, and any such rewrite still needs a manual check for behavior changes.

Line count and maintainability index

Lines of code counts source lines within each function's body; the maintainability index combines that count with cyclomatic complexity and Halstead volume, a measure of how many distinct and total operators and operands the code uses, into a single scaled score. A lower maintainability index flags a function that is denser and harder to change, independent of whether it merely looks long.

Good uses

Ranking every function in a file by cyclomatic complexity to decide which one to refactor first before a sprint
Checking a pull request diff for any function that crosses a team's complexity threshold, such as CC greater than 10, before approving the merge
Auditing a legacy module you just inherited to find which functions carry the most branching logic before writing tests for it

Limits and checks

Cyclomatic complexity counts branches, not readability - a switch statement over a dozen enum values can score high while remaining easy to follow at a glance
Code using syntax the parser cannot handle may fail to parse cleanly for that function, so an unexpectedly low or missing score is worth checking by eye rather than trusting outright
Maintainability index is a relative, not absolute, signal - two different tools can report different numbers for the same function because Halstead volume depends on exactly how operators and operands are tokenized

Common questions

Does a ternary or a && / || chain count toward complexity the same as an if statement?

That depends on the analyzer and isn't confirmed here for this tool specifically. What's consistent across virtually every implementation is that if and else if branches each add 1 to the baseline of 1. To get a definitive answer for ternaries or short-circuit operators, run a plain if version and a ternary or && version of the same function through the tool and compare the two scores.

Why does the lines-of-code number differ from what my editor's status bar shows for the same file?

The analyzer counts lines within each parsed function body rather than the whole file, so lines outside any function - imports, top-level constants, blank lines between functions - aren't attributed to a specific function's count. A whole-file line count from your editor or wc -l will usually be equal to or higher than the sum of every function's reported lines of code.

References and verification

The example and behavioral notes were checked against the browser implementation. Standards and primary references below define the relevant format, formula, or platform behavior.