Also called Code health score, Code quality score, Maintainability score
In depth Code health: the complete guide: every metric defined, score bands, validation and how to track it over time.
How code health is measured
There is no standard formula. The common shape: start each file at a perfect score, deduct for each problem found, clamp the result. Inputs:
- Structure: complexity, nesting, long functions, large classes, duplication.
- Change history: churn, authors, bug-fix commits.
- Tests: coverage, and whether tests reach complex code.
- Performance: I/O in loops, blocking calls in async code.
Why history belongs: a file with one CCN 30 function deducts for complexity either way. If it also changed 19 times this quarter and had three bug fixes, history deepens the deduction; if it has been stable for two years, it does not.
Why code health matters
Averages hide the files that matter. A repository can average 8 while a handful of heavily changed files sit below 4, and that is where bugs and slow reviews cluster. A per-file score turns "the codebase feels messy" into an ordered list, and a trend shows whether last quarter's cleanup moved anything.
How to measure code health yourself
No free tool gives one validated score, but you can assemble inputs:
- Complexity per function:
radon cc -s -a src/(Python),lizard src/(many languages), ESLintcomplexity,gocyclo -over 10 .(Go). - Churn from git:
git log --since="90 days ago" --name-only --pretty=format: | sort | uniq -c | sort -rn | head -20. - Coverage:
coverage.py(Python),c8or Istanbul (JavaScript). - An A to E rating from a remediation-cost ratio: SonarQube, the right pick for a rule-and-rating workflow; it does not weigh git history.
Files high on complexity, churn and missing coverage are the ones to read first.
How repowise measures code health
repowise scores every file from 1.0 to 10.0 with 59 deterministic detectors, with no LLM key or network. Each file starts at 10, findings deduct by severity times weight, and the result is clamped to 1 to 10. Of the 59 detectors, 23 move the defect score, 12 the maintainability score, 22 the performance score and 11 are advisory (listed, zero impact); a few feed more than one score.
Three signals come from the same findings and are never blended: code health (defect risk, the headline), maintainability and performance risk. History alone costs a file at most 1.0 point.
| Band | Score |
|---|---|
| Excellent | 8.5 and above |
| Good | 7.0 to 8.5 |
| Fair | 5.5 to 7.0 |
| Needs work | 4.0 to 5.5 |
| At risk | under 4.0 |
Validation: scored before the bug window and checked against the next six months of fixes, ROC AUC was 0.737 (95% CI 0.683 to 0.787) across 21 repositories, 9 languages and 2,826 labeled files. The score also orders a fixed review budget and says why each file ranks where it does. See the validation study.
Where to see it:
repowise healthfor fix-first items, KPIs and the lowest-scoring files;--file <path>for one file,--trendfor the last 10 snapshots,--badgefor README badge Markdown.repowise health check origin/main...HEADin CI: fails only on findings the change wrote.get_healthover MCP (one of the 10 repowise MCP tools), and the code health feature page.- Reference: code health docs.
A low score means look here first, not that the code is broken. Related: cyclomatic complexity, code smells, technical debt.