mcpField
C
cyclomatic-complexity

cyclomatic-complexity

github.com/saurabhkumar8112Development40886 installsUpdated 9w ago
Repository

About cyclomatic-complexity

cyclomatic-complexity is a skill for measuring and reducing code complexity, aimed at agents that write or maintain code. It defines thresholds and refactoring practices, with a workflow that checks behavior and complexity before and after changes.

Key features

  1. 01Measure and rank function complexity
  2. 02Apply project or default thresholds
  3. 03Refactoring tactics for branches and nesting
  4. 04Run tests before and after changes
  5. 05Report complexity before and after

Use cases

  1. 01Identify functions with high complexity
  2. 02Refactor code with growing branches
  3. 03Review maintainability of AI-written code
  4. 04Check behavior and metrics after refactoring

Install

Copy the command and run it in a terminal.

$npx skills add https://github.com/saurabhkumar8112/cyclomatic-complexity-skill --skill cyclomatic-complexity

After installing, type/cyclomatic-complexityin Claude Code to confirm it loaded.

Details

From the project README

Cyclomatic Complexity

Purpose: AI-written code often works but branches like a jungle. This skill: measure complexity, refactor hotspots, keep code human-maintainable.

Measure first

CC = decision points + 1. Decision points: if, else if, case, loops, catch, ternary, &&, || in conditions.

Project linter config wins. If eslintrc, radon config, sonar config, or similar sets a complexity threshold, use that. No config: use defaults below.

Thresholds:

  • 1-5: fine, leave alone
  • 6-10: watch, refactor if touching anyway
  • 11-15: refactor now
  • 15+: must split, no debate

Prefer real tools over eyeballing when environment allows:

  • Python: radon cc -s -a <path>
  • JS/TS: eslint complexity rule
  • Go: gocyclo
  • Polyglot: lizard <path>

No tool available: count manually, per function, show the count.

Refactor tactics, in order of preference

  1. Guard clauses. Invert conditions, return early, kill nesting.
  2. Extract function. Each extracted piece gets a name that says what, not how. Names are documentation.
  3. Lookup table / map instead of if-else or switch chains.
  4. Named predicates. if (isEligibleForRefund(order)) beats a 4-clause boolean soup.
  5. Polymorphism / strategy for switch-on-type. Only when the switch appears in 2+ places.
  6. Flatten loops. Extract loop body, use continue instead of nested if.

Hard rules

  • Preserve behavior. Run tests before and after. No tests: say so, suggest adding, refactor conservatively.
  • Don't game the metric. A dense one-liner hiding 6 branches is worse than the honest if-chain it replaced. Complexity should move into well-named units, not disappear into cleverness.
  • Don't break public APIs or exported signatures without asking.
  • Small functions with clear names > few functions with comments explaining sections.
  • One responsibility per function. If the name needs "and", split.

Workflow

  1. Measure all touched functions, rank by CC descending.
  2. Report hotspots with numbers before touching anything.
  3. Refactor worst first, one function at a time.
  4. Re-measure. Show before/after table: function, CC before, CC after.
  5. Verify: tests pass, behavior unchanged, diff reviewable.

Output format

End every refactor with:

## Complexity report
| Function | Before | After |
|----------|--------|-------|
| parseOrder | 14 | 4 |

Extracted: validateHeader, resolveDiscount
Behavior verified: <how>

Keep prose minimal. Numbers and diffs do the talking.

Comments

Markdown supported