Code Review Checklist: 7 Layers Every Pull Request Must Pass

Published August 2026 · 13-minute read · Category: Software Development

Most code reviews fail in the same way: the reviewer opens the PR, scrolls until something catches their eye, leaves a comment about a naming convention, and approves. The bug ships anyway. The reason isn't laziness — it's that without a code review checklist, a reviewer's attention is random. They notice what they happen to be good at (often style) and miss entire categories of defects (often logic and security) because nothing prompted them to look.

A checklist fixes this. It forces a reviewer to check every failure category in a fixed order, so the things humans miss without a prompt — race conditions, unvalidated inputs, missing tests for edge cases — actually get checked. This guide gives you a 7-layer code review checklist you can use on every PR today, explains how it compares to static analysis, and shows what changes when you review by language.

Frequently Asked Questions

The 7-Layer Code Review Checklist

The checklist below is organised by failure category, not by file or by importance. You work through the layers in order on every PR. Each layer has a small number of yes/no questions — if you can't answer "yes" to all of them, the PR is not ready to merge.

Layer 1 — Purpose and Scope

Before reading a single line of code, confirm the PR solves the right problem. This is the layer most reviewers skip, and it's the one where a catch saves the most time — a PR that solves the wrong problem is wasted work no matter how clean the code is.

• Does the PR link to a ticket or issue that describes the problem being solved?
• Does the changed code actually solve that problem, or does it solve a related but different one?
• Is there scope creep — changes unrelated to the stated goal (refactors, dependency bumps, formatting fixes mixed in)?
• Could this change be split into two smaller PRs that are independently revertable?
• Does the PR description explain why the change is needed, not just what changed?

If a PR has no description and no linked ticket, request both before reviewing further. You cannot evaluate correctness if you don't know what "correct" means.

Layer 2 — Correctness and Logic

This is the core of the review. Read the diff as if you were the compiler and the runtime at once. Look for the logic that is wrong but won't throw an error.

• Does each new function do what its name claims? Read the implementation, not just the signature.
• Are all branch conditions reachable? Look for dead branches and impossible combinations of flags.
• Are edge cases handled: empty collections, null/None/undefined, zero, negative numbers, very large inputs, unicode, timezones?
• For loops: what happens with an empty input, a single element, and the maximum expected size?
• Are comparisons using the right operator (== vs === in JS, == vs .equals() in Java, is vs == in Python)?
• For anything async: are errors in promises/futures/goroutines caught, or do they silently disappear?
• For anything with state: are there race conditions if two requests run at once?

The highest-value question in this layer is the race-condition one. Concurrency bugs don't show up in tests because tests usually run sequentially. Ask: "If this endpoint is hit by two users at the exact same millisecond, what happens?" If the answer involves a shared mutable variable without a lock, that's a bug.

Layer 3 — Security and Data Handling

Security review is where checklists pay for themselves. Reviewers miss security issues because they assume the framework handles them — and it usually does, until it doesn't. The checklist forces you to verify, not assume.

• Are all external inputs validated (length, type, format, range) before use?
• Are all outputs that include user data escaped for the correct context (HTML, JS, URL, SQL)?
• Are SQL queries parameterised, or is there any string concatenation building a query?
• Is authentication checked on every new endpoint or route, including internal/API routes?
• Is authorisation checked at the resource level (can user A access user B's data via ID in the URL)?
• Are secrets, tokens, and passwords kept out of logs, error messages, and URLs?
• For file uploads: is the file type validated, size limited, and stored outside the web root?
• Are new dependencies from a trusted source, and is the version pinned?

The authorisation question is the one that matters most. Most data breaches come from horizontal privilege escalation — user A can access user B's record by changing an ID in the URL — not from breaking authentication. Check that every new route that takes a resource ID also verifies the caller owns that resource.

Layer 4 — Tests and Coverage

A PR that adds code without tests is a PR that will break in a way no one notices for months. This layer ensures new behaviour is locked in.

• Does every new function with branching logic have at least one test per branch?
• Are edge cases tested (empty, single, max, invalid input)?
• Do the tests assert on behaviour (outputs, state) rather than implementation (mock call counts)?
• Do existing tests still pass, and has the author run them locally before requesting review?
• If the PR fixes a bug, is there a regression test that fails before the fix and passes after?
• Are test names descriptive enough that a failure message explains what broke?
• Is the test data realistic, or is it full of "test", 123, and foo that would mask real bugs?

If a PR fixes a bug but adds no test that reproduces it, the bug will come back. Require a regression test for every bug fix — no exceptions.

Layer 5 — Performance and Resource Use

Performance review is about catching the obvious problems, not micro-optimising. A reviewer's job is to flag things that will fall over at scale, not to debate whether a loop could be 2% faster.

• Are there N+1 queries — a query inside a loop that runs once per row instead of a single join?
• Are large collections loaded fully into memory when they could be streamed or paginated?
• Is any blocking I/O (file, network, DB) happening inside a hot path or a request handler that should be async?
• Are there unbounded loops or recursive calls without a depth limit?
• Are caches invalidated or expired when the underlying data changes?
• For API changes: does the response size grow linearly with data the user can control?
• Are new allocations in a loop that runs thousands of times per request?

The N+1 query is the single most common performance defect in code review, and it's invisible in local testing because local data sets are small. Look for any database call inside a for loop or a .map() callback. If you find one, it should almost always be a single query with a join or a batch load.

Layer 6 — Readability and Maintainability

This layer is where most reviews spend all their time and where they should spend the least. Style and naming matter, but only after the code is correct, secure, and tested. Don't let this layer crowd out the others.

• Do names (variables, functions, types) describe what they are, not how they're implemented?
• Is there a comment explaining why non-obvious code exists, not what it does?
• Is cyclomatic complexity reasonable — can you trace the logic without losing your place?
• Are functions doing one thing, or have several responsibilities accumulated in one body?
• Is dead code removed rather than commented out?
• Would a new team member understand this code without a walkthrough?

The test for naming: read the function name aloud and ask whether you could guess what it returns. If processData() could mean three different things, the name is wrong. Specific names — validateUserInput, filterActiveSubscriptions — are a form of documentation that never goes stale.

Layer 7 — Release and Rollback Readiness

The final layer asks: if we merge this and something goes wrong at 2am, what happens? A PR is only ready when it's safe to deploy and safe to undo.

• Is the change behind a feature flag, or does it deploy in one shot?
• Are database migrations backwards-compatible — can the old code still read the new schema, and vice versa?
• Is there a rollback path, and is it documented in the PR?
• Are there logging or metrics that will confirm the change is working in production?
• Does the PR author know how to revert if needed (revert button, migration down script)?
• For breaking changes: are downstream consumers notified and updated?

The migration question is the one that causes 2am pages. A migration that drops a column the old code still reads will take the service down the moment it deploys. Every schema change should be reviewed as a two-step deploy: ship code that tolerates the new schema, then ship the schema change, then ship code that uses it. If the PR combines all three steps, flag it.

Code Review Checklist vs. Other Approaches

Teams choose between several review methods. Here's how a structured checklist compares to the alternatives.

The right answer is almost always static analysis plus a checklist-driven human review. Let the tools catch the mechanical stuff so the human can spend their limited attention on the logic, security, and intent questions that tools can't touch.

What Changes When You Review by Language

The 7 layers apply to every language, but the specific things you look for in each layer shift. A reviewer who applies the same mental model to Python and Rust will miss language-specific footguns. Here's what to add per language.

Python

• Mutable default arguments (def f(x=[])) — a classic bug source.
• Bare except: clauses that swallow KeyboardInterrupt and SystemExit.
• Use of is for value comparison instead of == (works for None, fails for integers and strings).
• List comprehensions that leak the loop variable in Python 2-style code.
• Missing self, or static methods that should be instance methods.

JavaScript / TypeScript

• == vs === — loose equality is almost always a bug.
• Async functions without await, or await on non-promises.
• let used where const would do — and var anywhere.
• Unhandled promise rejections (no .catch(), no try/catch).
• In TypeScript: any types that defeat the type system, and non-null assertions (!) used to silence the compiler.

Java

• Use of == for object comparison instead of .equals() (especially strings).
• Autoboxing edge cases (Integer cache, null unboxing to NPE).
• Synchronization on non-final fields or on string literals (interning issues).
• Resource leaks — files/streams not in try-with-resources.
• hashCode/equals contract violations when one is overridden without the other.

Go

• Ignored errors (_ = err or just not checking the return).
• Goroutine leaks — goroutines started with no cancellation mechanism.
• Unbounded channel sends that can block forever.
• Mutex copies (passing a sync.Mutex by value instead of pointer).
• Defer in a loop causing resource buildup.

Rust

• unwrap() and expect() on values that could be None or Err in production paths.
• clone() used to fight the borrow checker when a reference would do.
• unsafe blocks without a safety comment explaining the invariant.
• Blocking I/O inside async contexts.
• Panic paths in library code that should return Result.

C#

• async void methods (exceptions can't be caught, crashes the process).
• .Result or .Wait() on async tasks — deadlock risk in sync contexts.
• Missing CancellationToken propagation in async chains.
• Struct mutations from readonly fields (defensive copy surprises).
• String concatenation in hot loops instead of StringBuilder.

Ruby

• nil propagation without &. safe navigation.
• Mutation of method arguments (especially default options hashes).
• rescue Exception catching everything including SystemExit.
• SQL built with string interpolation instead of parameterised queries.
• Class variables (@@) shared across inheritance hierarchies.

C / C++

• Buffer overflows and off-by-one in manual array indexing.
• Use-after-free and double-free (ownership unclear from the API).
• Missing null checks before dereference.
• Integer overflow in size calculations before allocation.
• Format string bugs — user-controlled data passed as the format string.
• Missing initialisation of stack-allocated structs.

These lists aren't exhaustive, but they cover the defects that show up repeatedly in each language's code review. The Code Review Handbook has a full section per language with more items and examples.

How to Leave Review Comments That Get Fixed

A checklist tells you what to check. How you raise what you find determines whether the author fixes it or argues about it. Three principles make review comments land:

1. Ask, don't tell. "Could this loop run with an empty list?" is more effective than "This will crash on empty input." It lets the author save face and often surfaces context you didn't have.
2. Explain the failure, not the fix. "A user with an expired token will see a 500 here" beats "Add a try/catch." The author knows their code better than you do — tell them the problem and let them pick the solution.
3. Distinguish blocking from optional. Prefix comments with "Blocking:" for must-fix issues and "Nit:" for stylistic preferences. This saves the author from treating every comment as equal and lets them focus on the ones that matter.

A phrase bank helps here. Instead of rewriting "this variable name is unclear" for the hundredth time, a reviewer can draw from a set of pre-written, neutral phrasings. The Handbook includes 50+ such phrases for common review situations — all calibrated to be specific without being personal.

Measuring Whether Your Reviews Are Working

A checklist is only useful if it's actually improving quality. Track these six metrics to know whether your review process is healthy:

If your post-merge defect rate isn't falling after you adopt a checklist, the most likely cause is that reviewers are ticking boxes without actually checking — going through the motions. Spot-check by reading a sample of approved PRs and seeing whether the checklist items were genuinely verified.

A 30-Day Plan to Build Review Culture

Adopting a checklist is a behaviour change, not a document. The checklist fails if it lives in a wiki no one opens. Here's a 30-day plan to make it stick:

• Days 1-7: Paste the 7-layer checklist into your PR template so it appears automatically on every new PR. Don't enforce it yet — just let reviewers see it.
• Days 8-14: Start using it yourself on every review you do. Note which items you skip and why — some may not apply to your codebase and can be pruned.
• Days 15-21: In a team retro, share what you've found. Get agreement on which layers are mandatory-blocking and which are advisory.
• Days 22-30: Add the language-specific items for your stack. Start tracking the six metrics above to establish a baseline.

After 30 days, the checklist should feel like a habit, not a formality. If reviewers are still skipping it, the problem is usually that the list is too long — prune anything that hasn't caught a real defect in the first month.

Putting It All Together

A code review checklist works because it replaces random attention with systematic attention. The seven layers — purpose, logic, security, tests, performance, readability, and release — cover the categories of defects that reach production. The language-specific additions catch the footguns unique to your stack. The comment principles make what you find actually get fixed. And the metrics tell you whether the whole system is working.

If your team's reviews currently consist of "looks good to me" and a thumbs-up, you are catching a fraction of the bugs you could. A checklist takes 15 minutes to apply and catches the rest. Start with the 7 layers above on your next PR.