What this estimate does and does not do
This calculator estimates reviewer effort for a code review or pull request. It uses changed lines of code, files changed, inspection rate, and multipliers for complexity, familiarity, and risk.
It does not measure review quality, author rework time, CI time, queue time, or total lead time to merge. A fast review can still miss serious defects, and a long review can still be unproductive if the change is too large or poorly prepared. Use this as a planning and PR-sizing tool, not as a guarantee of defect detection.
Formula used
LOC review hours = changed LOC / inspection rate
file overhead hours = files changed × minutes per file / 60
base hours per reviewer = LOC review hours + file overhead hours
multiplier = complexity × familiarity × risk × author preparation factor
hours per reviewer = base hours per reviewer × multiplier
total reviewer-hours = hours per reviewer × reviewer count
suggested sessions = max(ceil(LOC / max LOC per session), ceil(minutes / max minutes per session))The author preparation factor reduces the estimate when the author has self-reviewed, summarised the change, and added notes for reviewers. It increases the estimate when reviewers have to infer context themselves.
Worked example
For a pull request with 350 changed LOC, 6 files, 2 reviewers, 300 LOC/hour inspection rate, 2 minutes overhead per file, medium complexity, medium familiarity, medium risk, and author preparation:
LOC review hours = 350 / 300 = 1.17h
file overhead = 6 × 2 / 60 = 0.20h
base = 1.37h
author preparation factor = 0.90
time per reviewer = 1.37 × 0.90 = 1.23h = 73.8 minutes
total reviewer-hours = 1.23 × 2 = 2.46hWith a 60-minute session limit, the calculator recommends splitting the review into 2 sessions.
How to use the result
- If the review is over 400 LOC, consider splitting it.
- If time per reviewer exceeds 60–90 minutes, split into sessions or reduce scope.
- If the review touches many files, add a clear author summary and route to domain owners.
- If the code is high risk, add reviewers, security checks, test evidence, or architecture review.
- Track your own review rates, pickup time, defect escapes, and rework to calibrate the estimate.
Assumptions and limitations
- LOC is only a proxy for review effort. A 20-line concurrency bug can be harder than a 300-line UI copy change.
- Generated code, formatting-only diffs, lockfiles, and vendored files should usually be separated from logic review.
- The calculator estimates active reviewer effort, not waiting time.
- Multiple reviewers increase total effort even if calendar time is parallel.
- Review effectiveness depends on team norms, tests, checklists, author preparation, and reviewer focus.
Frequently asked questions
How long should a code review take?
Many code review best-practice sources recommend limiting a focused review session to around 60 minutes and avoiding sessions longer than 90 minutes.
How many lines of code should be reviewed at once?
A commonly cited SmartBear/Cisco benchmark recommends reviewing fewer than 400 lines at a time, with 200–400 LOC over 60–90 minutes often used as a practical target.
What LOC per hour should I use?
Around 200–400 LOC/hour is a common planning range for careful review. Rates above about 500 LOC/hour risk skimming and lower defect detection.
Does this estimate include author fix time?
No. It estimates reviewer effort only. Author response time, rework, CI fixes, and follow-up review rounds should be estimated separately if needed.
Should generated files be included?
Usually no. Generated files, lockfiles, formatting-only diffs, and vendored code should be reviewed separately or excluded from meaningful LOC-based review estimates.