Calculator
Enter your repository metrics for a sprint, week, or release window.
Formula used
Line Coverage (%)
line_coverage = (reviewed_lines / total_lines) × 100
PR Coverage (%)
pr_coverage = (reviewed_prs / total_prs) × 100
Weighted score (%)
score = (line_cov×w_line + pr_cov×w_pr) / (w_line + w_pr)
Effort + penalty
effort = (review_hours / dev_hours) × 100
penalty = max(0, (10 − effort)/10 × 15)
adjusted = clamp(score − penalty, 0, 100)
Defects per KLOC reviewed
defects_per_kloc = defects_found / (reviewed_lines / 1000)
This is a signal, not a target. Very low values can mean shallow reviews.
How to use this calculator
- Pick a consistent window: weekly, sprint, or release.
- Collect totals: changed lines, PR count, and review completion.
- Add reviewer time and development time from your tracking.
- Adjust weights to match your policy and risk tolerance.
- Run the calculator and compare scores across windows.
- Export CSV for trend charts and audit trails.
Example data table
These rows show typical sprint metrics and results.
| Window | Changed LOC | Reviewed LOC | Total PRs | Reviewed PRs | Defects | Review hrs | Dev hrs | Adj. score | Rating |
|---|---|---|---|---|---|---|---|---|---|
| Sprint 12 | 1800 | 1600 | 22 | 21 | 14 | 18.5 | 120 | 83.9% | Good |
| Sprint 13 | 2400 | 1700 | 26 | 23 | 11 | 14.0 | 135 | 66.8% | Fair |
| Sprint 14 | 1500 | 1480 | 19 | 19 | 9 | 17.0 | 110 | 94.1% | Excellent |
Your recent history (saved runs)
| Date | Line cov | PR cov | Effort | Defects/KLOC | Adj. score | Rating |
|---|---|---|---|---|---|---|
| No saved runs yet. Enable “Save this run to history”. | ||||||
FAQs
1) What is code review coverage?
It estimates how much work was checked by reviewers. This calculator reports coverage by changed lines and by pull requests.
2) Why track both line coverage and PR coverage?
Line coverage captures depth across changed code. PR coverage captures process compliance, ensuring every change gets reviewed.
3) What does “review effort” mean here?
Review effort is review hours as a percentage of development hours. Very low effort can make high coverage look better than it is.
4) Does a higher defects-per-KLOC value mean worse code?
Not always. A moderate value can mean reviewers are catching real issues. Extremely low values may indicate reviews are superficial.
5) How should we choose weights?
If you fear unreviewed PRs, increase PR weight. If large diffs slip through, increase line weight. Keep weights stable for trend tracking.
6) Can this replace automated tests or static analysis?
No. Reviews are complementary. Use this score alongside test coverage, CI quality gates, and production incident metrics.
7) What score should we aim for?
Many teams target 75–90% adjusted score, depending on risk. The best target is one that predicts fewer escapes and stable delivery.