A code review checklist that fits in your head: three passes, seven questions

Most code review checklists fail the same way: they are written to be complete instead of usable. Forty items, three categories deep, checked by nobody after week two. A code review checklist earns its keep only if it fits in your head, because the whole point is to shape attention while you read, not to generate a compliance artifact afterward. Here is the version we actually use: three passes, seven questions, and clear rules about when to put the list down.

Three passes, in this order

Attention is the scarce input, so spend it in decreasing order of consequence. First pass: correctness. Does the logic do what the PR description claims, and what happens when inputs are hostile or dependencies fail? Second pass: design. Is this the right shape for the change, does it fit the surrounding system or fight it? Third pass, always last: style, and only what automation could not already flag. This is the same discipline we recommend in how to review large pull requests, and it matters because the reverse order is seductive: naming nits are easy to find and produce the feeling of review without its substance. The SmartBear peer review research caps effective review around 400 lines and an hour per session; passes force you to spend that budget on verdicts that matter before it runs out.

The code review checklist: seven questions

1. Does it do what the description says? Not approximately: trace at least one real path from entry to effect.
2. What happens on the unhappy path? Bad input, timeout, partial failure, double submit. Most escaped bugs live here.
3. Will someone understand this in six months? If you needed the author to explain it, the next reader will too, and they will not have the author.
4. Does it fit the existing design or fight it? A locally clean change that duplicates or bypasses an existing mechanism is a design bug.
5. What do the tests actually assert? Read the assertions, not the test count. Weakened or deleted assertions are the highest-signal lines in a diff.
6. What breaks downstream? Callers, consumers, migrations, API contracts: the blast lives outside the diff.
7. Would I own this line in production? If the pager went off tonight and this line was the cause, would you stand behind having approved it?

Seven is deliberate. It is small enough to run from memory on every review, which means it actually gets run. Notice what is absent: formatting, naming conventions, import order, anything a machine can check. A human checklist that duplicates the linter trains reviewers to do a robot’s job badly while the judgment questions go unasked. If an item on your current template could be a CI rule, make it one and delete the checkbox.

When checklists help

Checklists earn their keep wherever reviewer behavior is inconsistent. New team members learn what the team considers reviewable by seeing the same seven questions asked repeatedly. Microsoft’s study of modern code review ( Bacchelli and Bird) found that understanding the change is reviewers’ top challenge, and a short question list is a comprehension scaffold: it tells you what to try to understand first. Checklists also depersonalize feedback. “Question five: the test asserts nothing about the error case” reads as process, not accusation, and pairing it with the Conventional Comments format (issue, suggestion, nitpick, praise) keeps threads legible. The label does double duty: it tells the author which comments block the merge and which are take-it-or-leave-it, which is half of what review arguments are actually about.

When checklists hurt

The failure mode is the checklist as liturgy: a template pasted into every PR, every box dutifully ticked, no box ever meaning anything. That is not review with extra steps, it is review theatre with better paperwork, and it is arguably worse than honest rubber-stamping because the artifact claims diligence that never happened. The tell is uniformity: when a trivial README fix and a payment-path change produce the same ticked boxes in the same thirty seconds, the checklist has stopped shaping attention and started laundering its absence. Checklists are prompts for thought. The moment compliance becomes the deliverable, delete the template and keep the questions.

Adapt it per tier

Not every change deserves all seven questions at full depth, and pretending otherwise is how the list decays into ritual. Scale it with blast radius: a docs change gets questions one and three; a schema migration or auth change gets all seven, slowly, plus a second reviewer. The checklist is the constant; the depth per item is the dial. Teams that make that dial explicit spend their review hours where wrongness is expensive, and their checklist survives because nobody is forced to perform it where it is pointless. Seven questions, three passes, one dial. That is the whole system, and it fits in your head, which is the only place a checklist ever actually runs.