Code Review Checklist

A structured checklist for reviewing pull requests that catches bugs, enforces standards, and improves code quality across your team.

Checklist: Code Review (engineering)

Effective code reviews catch bugs, enforce standards, and share knowledge across the team. This checklist provides a structured approach so reviewers consistently evaluate correctness, readability, security, and performance without relying on memory.

Checklist Items

  1. Verify the PR description explains the why [critical]: Ensure the PR includes context on why the change is needed, not just what changed.
  2. Check for correctness and edge cases [critical]: Verify logic handles null values, empty collections, boundary conditions, and error states.
  3. Review security implications [critical]: Check for SQL injection, XSS, CSRF, auth bypass, and sensitive data exposure.
  4. Evaluate test coverage [important]: Ensure new logic has unit tests and edge cases are covered. Check that tests are meaningful, not just hitting lines.
  5. Assess readability and naming [important]: Variable and function names should be descriptive. Complex logic should have comments explaining intent.
  6. Check for performance concerns [important]: Look for N+1 queries, unnecessary re-renders, large memory allocations, and missing pagination.
  7. Verify API contract changes are backward compatible [important]: Ensure API changes do not break existing consumers without a versioning strategy.
  8. Check for proper error handling [recommended]: Verify errors are caught, logged with context, and surfaced to users with actionable messages.
  9. Look for duplicated logic [recommended]: Identify code that duplicates existing utilities or patterns and suggest reuse.
  10. Verify linting and formatting pass [recommended]: Ensure CI checks for linting, formatting, and type checking all pass before approving.

Common Mistakes

  • Rubber-stamping large PRs: Break large PRs into smaller, focused changes. If a PR is too large to review carefully, request it be split.
  • Only reviewing the diff, not the context: Open the full file to understand the surrounding code. Diffs hide important context.
  • Focusing only on style, not substance: Automate style enforcement with linters. Spend review time on logic, security, and design.

Frequently Asked Questions

How long should a code review take?
Most PRs should be reviewable in 15-30 minutes. If it takes longer, the PR is probably too large and should be split.
Should the author or reviewer write tests?
The author should include tests with the PR. The reviewer should verify test quality and suggest missing cases.
How do you handle disagreements during review?
Focus on facts, link to documentation, and escalate to a team lead if consensus cannot be reached. Never block PRs over style preferences.