Code Review Best Practices That Survive Reality

TL;DR: Most code review advice is folklore. The practices with actual evidence behind them: keep changes at 200-400 lines, get the first response inside hours not days, review with a checklist that targets what review actually catches, spread the load past one overworked senior, and track whether every change gets a second reader at all. Skip the rest.

Every team has a code review process. Very few have one that was designed. Most inherited a pile of habits: the template nobody fills in, the two-approval rule someone added after an incident in 2021, the senior who reviews everything because "it's faster." This page is the hub for doing better. It covers what the research supports and what it quietly debunks, with a deep-dive linked for each.

What code review actually catches

Start with an uncomfortable finding, because it reframes everything else. Mäntylä and Lassenius manually classified defects found in code reviews and discovered that 75% are evolvability defects - problems of structure, naming, and clarity that don't change what the software visibly does. Only a quarter are functional bugs.

Microsoft found the same gap from the other direction. Developers say finding defects is their top motivation for review. When Bacchelli and Bird classified real review comments, the outcomes were less about defects than expected and more about knowledge transfer, team awareness, and better solutions.

So no, review is not a bug net with a 25% catch rate. It's the mechanism that keeps a codebase changeable and a team interchangeable, which is also why "we have tests, do we still need review?" answers itself. Tests check what the code does; review checks whether anyone else can work on it. Judge your practices by that standard and half the folklore falls away.

How big should a pull request be?

The single most load-bearing number in code review comes from SmartBear's study at Cisco: reviewers are effective on 200-400 lines of code at a time, where a careful pass yields 70-90% defect discovery. Past that, attention collapses. Defect density drops sharply once reviewers move faster than 500 lines per hour, and a 1,500-line PR guarantees they will.

LinearB's benchmarks across 8.1 million+ PRs agree from the field: elite teams keep PR size under 100 changed lines. Treat small PRs as the operating condition for everything else on this page. The full case, including why big diffs get worse review rather than just slower review, is in Why Small Pull Requests Win.

How fast should a review start?

Google's study of roughly 9 million reviewed changes found the median time for the entire review process is under 4 hours, with small changes getting first feedback in under an hour. LinearB's bands put elite pickup time under 1 hour and flag anything past 16 hours as "needs focus."

If your PRs take days, the gap between you and those numbers is rarely reading speed. The diff sits untouched while its author context-switches away. That waiting is the cheapest thing in your whole process to remove. Start with pickup time, the first review metric worth watching. Triage a stuck PR instead of guilt-tripping its author in standup, and put a number on the delay's real payroll cost. The DORA 2023 report gives you the business case for fixing it: teams with faster review show ~50% higher software delivery performance.

What should reviewers actually look for?

Given that 75% of review findings are evolvability issues, a reviewer's attention should be spent accordingly: understanding first, correctness and blast radius second, style never (that's a linter's job). Bacchelli and Bird identified understanding the change as the central challenge of modern review. Most bad reviews fail at comprehension long before they fail at diligence.

The concrete, ordered version lives in The Code Review Checklist Seniors Actually Use: what to check first, what to automate away, when to stop. If you're evaluating whether AI reviewers can take some of this load, the honest answer is "the mechanical parts, yes." The AI code review tools guide covers where they genuinely help and where they confidently miss the point.

Who should review? Spreading the load

The team where one senior reviews everything has three problems wearing one trench coat: review speed capped by one calendar, a burnout candidate, and a bus-factor risk. When that senior is out, merging stops.

The fix is deliberate rotation, with a calibration point attached: Google's median change has exactly one approver. Three reviewers per PR is overkill; what pays off is different single reviewers across PRs. One clearly named owner per review beats a CC list, because responsibility divided by three rounds to zero. Let mid-level engineers review with the senior as backstop - reviewing is how they become the people you currently can't live without.

Every change needs a second reader

At Google, essentially every change to the main codebase is reviewed before it lands. On most teams, some percentage of PRs quietly merges with zero reviewers, and nobody tracks that number. Standard dashboards measure review speed and skip the question of whether the review happened at all.

That's review coverage, the most underwatched metric in this whole pillar. Unreviewed code is single-reader code: whatever it does, one person knows. Given that knowledge transfer is one of review's biggest measured outcomes, every silent self-merge is a small deposit into your knowledge-silo account.

Rituals the evidence does not support

Honesty cuts both ways, so here is what you can skip:

• Mandatory multiple approvals for everything. Google ships with a median of one. Blanket two-approval rules mostly double queue time and halve accountability. Reserve extra eyes for genuinely dangerous surfaces - migrations, auth, payments.
• Style comments from humans. Every naming debate in a review thread is friction wearing a quality costume. Automate formatting and convention; spend humans on design and blast radius.
• Review-time theater: templates nobody reads, checklists pasted and ignored, "LGTM" from someone who opened the diff for 40 seconds. A rubber stamp is a disconnected smoke alarm.
• Shaming the slow. A stuck PR is a system signal, usually blocked, abandoned, or too big to face. Diagnose it quietly instead of performing it in standup.

Where to start

If you change one thing this quarter, shrink the PRs. Pickup gets faster, review gets deeper, coverage gets cheaper, and every other practice on this page gets easier downstream of that one change. Then instrument the pipeline so you can see pickup, size, load, and coverage instead of arguing about them. That is exactly what a review-friction breakdown is for.

Code review done well is the second reader every change deserves - and the only scalable way a codebase stays understood by more than its authors.