Code Review Checklist

A code review checklist is a structured set of things a reviewer checks on every code change, so review quality doesn't depend on which reviewer happens to pick it up or how much time they have that day. It's a floor, not a substitute for actually understanding what the change does — a good review still requires reading and thinking about the code, with the checklist making sure nothing load-bearing gets skipped under time pressure.

Key components

• Correctness — does the change do what it claims to do, including edge cases and error paths, not just the happy path demonstrated in the description or a screenshot.
• Test coverage — are the new or changed behaviors actually covered by tests, and do the tests verify the behavior rather than just exercise the code without meaningful assertions.
• Readability and naming — can someone unfamiliar with this change understand it from the code and its names alone, without needing the author to explain it in person.
• Security-sensitive patterns — unvalidated input, secrets in code or logs, missing authorization checks, unsafe deserialization, and other patterns that need scrutiny regardless of what the change is nominally about.
• Scope — is this change doing one coherent thing, or has it quietly grown to include an unrelated refactor, a drive-by fix, or a second feature that should have been its own change.

Checklist as consistency, not a substitute for thought

A checklist earns its place by making review quality consistent — every reviewer checks the same baseline things, regardless of mood, familiarity with the code, or how much time is left in the day. It fails when it becomes the review: ticking boxes ("tests present: yes," "naming ok: yes") without actually engaging with whether the change is correct or whether the tests test the right thing turns review into theater. The checklist should prompt a reviewer to look in the right places; it can't do the looking for them.

Common pitfalls

• Applied mechanically without engaging with the change — a reviewer who checks every box but never actually reasons about whether the logic is correct produces an approval that looks thorough and isn't.
• Reviews that only check style and formatting — surface-level issues are the easiest to spot, so a rushed or checklist-only review gravitates to them while correctness and security issues, which take real reading to catch, slip through unexamined.
• No consistent standard across reviewers or moods — the same reviewer approves a thorough change one day and rubber-stamps a risky one the next because of time pressure, familiarity with the author, or fatigue, with no checklist to anchor a consistent bar.
• Checklist too long to actually use — a checklist with forty items gets skimmed or ignored rather than applied; a shorter list that's actually followed beats a comprehensive one that isn't.
• Scope creep waved through — an unrelated change bundled into an otherwise-fine PR gets approved along with it because reviewing scope wasn't explicitly part of what to check.
• No path for disagreement — a checklist treated as a strict gate with no room for reviewer judgment on a specific case turns review into bureaucracy instead of a quality check.

Learn more

• Refactoring for the practice of restructuring code that a reviewer is often evaluating, as distinct from the checklist used to evaluate it.
• Technical Debt Register for tracking a shortcut a reviewer flagged but chose to approve anyway, so it stays a visible, tracked decision.
• Architecture Decision Record for the record a reviewer can check a change against when the change touches a decision that was already made and documented.
• Postmortem for how a bug that slipped through review sometimes becomes the reason a checklist item gets added.