find-complexity

Find Complexity Hotspots

Identify functions that are hard to review, test, and maintain.

Rules

• Report findings, do not refactor. Refactoring is a separate task.
• Focus on production code (ols/). Skip tests unless explicitly asked.
• Rank by severity: highest complexity first.

Step 1: Determine Scope

Ask the user:

• Branch mode: only files changed in the current branch vs main.
• Full mode: scan the entire ols/ directory.

For branch mode:

git diff --name-only origin/main -- 'ols/' | grep '\.py$'

Step 2: Cyclomatic Complexity

uvx radon cc <target> -s -n C -a

This shows functions with complexity grade C or worse (threshold: 11+).

Grades: A (1-5), B (6-10), C (11-15), D (16-20), E (21-25), F (26+).

Step 3: Maintainability Index

uvx radon mi

This shows files with maintainability grade B or worse.

Grades: A (20+, good), B (10-19, medium), C (0-9, poor).

Step 4: Cognitive Complexity

Cognitive complexity weights nesting depth — a 5-deep if scores much higher than 5 sequential ifs.

Step 5: Function Length

Find long functions (30+ lines of logic, excluding docstrings and blank lines):

Also use pylint for method length:

Step 6: File Size

Find large files (500+ lines):

Files over 500 lines are candidates for splitting into focused modules.

Step 7: Classify Findings

For each function found, classify:

Step 8: Report

For each finding:

1. File, function name, line number
2. Complexity grade and score
3. Number of statements / arguments
4. Classification (split / simplify / parameterize / monitor)
5. Brief suggestion

Summary: total hotspots by grade, top 5 worst offenders.