The Code Review Checklist for Engineering Teams

Most code review checklists stop at the file level: does the function name make sense, are there tests, is input validated? Useful, but they share one blind spot. They assume the code change is self-contained, judgable without looking past the diff.

In a real codebase, that falls apart. A reviewer who inspects only the changed lines misses the auth check that needs updating elsewhere, test cases about to break in a sibling service, and the downstream consumer with no idea the contract just changed. This code review checklist is built for codebases too big for one head and adds a dimension most lists ignore: whether the new code is consistent with the rest of the codebase.

What Should You Look for in a Code Review?

When a PR lands in your queue, don't start at line one. The most useful first pass is a five-question scan of the code change as a whole:

• Correctness. Does it do what the description says, and handle edge cases and logic errors?
• Readability. Will the engineer who picks this up in six months understand it?
• Tests. Meaningful test cases, or do they just assert that mocks are still mocks?
• Architecture. Is the proposed solution well-designed and consistent with existing patterns?
• Security. Is user input validated, authentication handled correctly, and sensitive data protected with appropriate measures?

If those answers are "yes," start reading line by line. If any is "no," focus the review there first. Per Google's engineering practices, the bar in code reviews is whether the code change improves overall code quality, not whether it's perfect. Code quality is the goal.

The Master Code Review Checklist

Items are ordered by the cost of getting them wrong. A correctness bug ships to production; a naming nit costs at most a follow-up commit.

Correctness & functionality

Correctness is the reason code reviews exist. Everything else on this list is long-term hygiene; this is where a missed branch breaks production tonight.

• The code change does what the description claims; the description matches the diff.
• Error handling is real, not swallowed; error messages are clear and actionable.
• Edge cases are covered: empty, null, zero, negatives, very large inputs, concurrent calls, and partial failures.
• Concurrency primitives have been read carefully. Race conditions are easy to miss in code reviews and often escape ordinary tests, so invariants are stated explicitly.

Readability & maintainability

Code is read more often than written, and the audience is the engineer who picks it up six months from now. The reviewer's job is to ask whether they'll understand it without paging in context.

• Variable names describe what the thing is, not how it's implemented.
• Functions follow the single responsibility principle; if you can't summarize one in a sentence, it's a candidate to split.
• Comments explain why, not what. Redundant or outdated comments, commented-out code, and orphaned TODOs are removed.

Tests & coverage

Tests are part of the code change, not an afterthought. A reviewer who approves untested behavior is signing up to debug it later.

• New behavior has unit tests; existing tests still cover the contract.
• Test cases assert on outcomes (not implementation), with names that describe the scenario.
• Flaky tests aren't "fixed" by retries (e.g., due to a potential race condition).

Performance

Performance bugs rarely surface against the seed fixture; they show up in production after the diff has shipped. The cheapest place to catch them is in the review.

• No N+1 queries inside a loop; no unbounded growth (queue with no max, cache with no eviction, retry with no backoff).
• Database changes are reviewed against actual table sizes for system performance.

Security

Small misses here become CVEs. Walk through the change like an attacker, not just a user, and assume anything user-supplied is hostile until proven otherwise.

• User input is validated server-side against an allowlist where possible.
• Authentication is handled correctly on every new entry point; authorization runs after authentication and before the action.
• Sensitive data is not in the diff, config, test fixtures, or commit messages.
• SQL injection is prevented with parameterized queries; output is encoded to prevent cross-site scripting.
• Enough log events to detect security attacks, without writing secrets to logs.

Architecture & design

The question isn't whether the design is correct in the abstract; it's whether it fits the system it's joining. New patterns are expensive even when they're better than the old ones.

• The code change fits existing language-specific patterns; a new pattern is justified.
• Over-engineering tends to be the more frequent failure mode and harder to remove.
• The code is modular (dependency injection, interface segregation, clear seams) and testable.
• Public API contracts are stable, versioned, or explicitly breaking.

Cross-cutting impact

The item every other code review checklist skips, and the one that catches up with you in production. A diff that looks clean in the file view can leave the rest of the codebase out of sync.

• Every call site of every modified function has been checked; a signature change isn't done when the file compiles.
• Downstream services consuming the contract are identified; backward compatibility is preserved, or the break is documented.
• Codebase-wide patterns (logging, error handling, metrics, and auth middleware) are applied consistently. An endpoint missing standard auth middleware is a common source of permission bugs.
• The data flow is understandable: where data is retrieved, how it moves, and where it lands.

Most code reviewers can't answer "where else is this used?" inside a single PR view, which is why this item escapes review most often.

Documentation & changelog

Documentation drift is invisible during the review and painful to recover from later. Treat it as part of the code change, not a follow-up.

• Docs, READMEs, and API references are up to date with the new behavior.
• The changelog tells downstream consumers what they need to know.

Specialized Checklists

The master checklist above covers most code changes, but for higher-risk surfaces, layer one of these additional checklists into the mix as well:

Secure code review checklist (OWASP-anchored)

For code touching authentication, authorization, cryptography, or user input, anchor the security pass on the OWASP Code Review Guide categories: server-side allowlist validation, parameterized SQL to block SQL injection, output encoding, centralized authorization that fails closed, vetted crypto, and error messages that don't leak stack traces.

Frontend code review checklist

State at the right level, correct effect dependencies (For example, stale closures are a common source of subtle React bugs), bounded renders, accessibility, and bundle impact for new dependencies.

Backend/API code review checklist

Endpoints follow existing patterns; schemas are explicit; timeouts and cancellation propagate end-to-end; idempotency is guaranteed for retryable operations.

Database/migration code review checklist

Migrations are reversible. For large production tables, additive changes are staged: nullable column, backfill, then NOT NULL. New indexes use the online or concurrent path where available (CREATE INDEX CONCURRENTLY on Postgres) and run against production-scale data.

How to Use This Checklist Effectively

Code reviews work best when this checklist is a tool, not a script. The goal of code reviews is to improve and maintain standards and quality, not to have the entire dev team resent you as a person by digging way too hard into stuff that is not overly meaningful. Here are a couple of tips to keep that balance in check:

Don't comment on every item; prioritize blocking issues

Blocking comments are about correctness, security, and design. Nits are coding style and polish; mark them as nits so the author can address them in one commit.

Calibrate by PR risk

Match the depth of the code review process to the blast radius. A two-line bugfix ships in five minutes; a change to auth middleware doesn't.

Pair the checklist with automated tools

Static analysis, linters, and SAST tools should catch code formatting and naming conventions before a human looks. Automate the boring half; let code reviewers focus on whether the code adds the right thing.

Code Review Checklist for Reviewing AI-Generated Pull Requests

The newest entry in every code reviewer's day is the AI-generated PR: the agent writes, opens the PR, and the human approves. The checklist is mostly the same, but two items move from "watch for" to "assume until proven otherwise."

Assume the agent missed the cross-cutting work. Agents are good at editing the file they're pointed at, but routinely miss call sites and conventions outside the immediate context. A code change that adds a Role field to a User struct can compile and pass tests, while auth middleware, response DTOs, the audit log, the invite flow, and admin routes silently behave as if the field doesn't exist.

Assume the tests are weak. Agents happily produce test cases that assert on the mocks they wrote. If you deleted the production change but kept the tests, would they still pass? If yes, they're vacuous.

Tools like Amp try to close the context gap by giving the agent the codebase intelligence a reviewer has, but the reviewer still verifies the proposed solution. Sourcegraph's security team documented what happens when an LLM joins the code review process without that context: false positives drown out real findings.

Beyond the Checklist: When You Need Codebase-Wide Context

A code review checklist asks, "Is this code change good?" The harder question, "is it consistent with the codebase?", doesn't fit in a checkbox. The answer lives in code that the reviewer can't see in the diff.

This is the gap Sourcegraph was built for. Code Search answers "where else is this used?" across multi-repository codebases in milliseconds, turning the cross-cutting item from a best-effort check into something a reviewer can verify. Code Insights tracks search-defined patterns over time: endpoints skipping standard auth middleware, manifests referencing vulnerable Log4j ranges, and TODOs aging in a team's directory. The Sourcegraph MCP server hands the same context to AI agents, so they find related call sites before proposing a change.

None of this replaces the checklist; it makes the checklist answerable on a codebase larger than one head can hold.

Conclusion

A great code review covers correctness, security, readability, tests, and architecture, plus one thing the diff can't show: consistency with code the reviewer can't see. The first five become muscle memory; the sixth takes tooling. To see how Sourcegraph closes the cross-cutting gap for reviewers and AI agents, schedule a demo.

Frequently Asked Questions

What are the 7 steps to review code?

(1) Read the description and confirm intent; (2) check correctness and edge cases; (3) check unit tests and automated tests; (4) check security vulnerabilities and input validation; (5) check the proposed solution against existing design patterns; (6) check cross-cutting impact on code elsewhere; (7) leave prioritized, actionable feedback.

What should be included in a code review checklist?

Correctness, readability, test cases, security and data privacy, architecture (does the code adhere to design patterns and the single responsibility principle?), cross-cutting impact, and documentation.

What is done during code review?

Code reviewers verify that no logic errors, error handling, and naming conventions are sound, sensitive data is protected with appropriate measures, input parameters are validated, and no security vulnerabilities are introduced.

What to look for during a code review?

Correctness, readability, meaningful test cases, security vulnerabilities, fit with existing design patterns, and cross-cutting impact. See "What Should You Look for" above for the deep version.