Code Review Checklist
A pull-request code review checklist — reviewer and PR details plus grouped checks for correctness, tests, performance, security, readability/docs, and a review decision.
Live preview
CODE REVIEW CHECKLIST PR: #1234 — feature/add-export Author: Sample Author Reviewer: Sample Reviewer Summary: Adds CSV export to the reports page. CORRECTNESS [ ] Does what the PR/issue describes; edge cases handled [ ] Logic is correct; no obvious off-by-one / null / async bugs [ ] Error handling is present and sensible [ ] No leftover debug code, console logs, or commented-out blocks TESTS [ ] New/changed behavior is covered by tests [ ] Tests are meaningful (not just snapshots) and would catch regressions [ ] Tests pass locally / in CI [ ] Edge cases and failure paths are tested PERFORMANCE [ ] No needless work in hot paths or loops (incl. N+1 queries) [ ] Large data handled efficiently; pagination/streaming where needed [ ] No obvious memory leaks or unbounded growth SECURITY [ ] Input is validated; output is escaped/encoded (no injection/XSS) [ ] No secrets, keys, or credentials committed [ ] AuthZ/AuthN checks where required; least privilege [ ] Dependencies are trusted and up to date READABILITY & DOCS [ ] Clear names; reasonable function/file size; matches code style [ ] Comments explain the "why" where non-obvious [ ] Public APIs / README / docs updated as needed [ ] No unrelated changes mixed into this PR ADDITIONAL CHECKS [ ] Feature flag added and defaulted off [ ] Analytics event fires on export [ ] Changelog updated DECISION: Comment NOTES Looks solid. Two small naming nits inline; please add a test for the empty-data case.
About this template
A code review checklist makes reviews more consistent and less dependent on whoever happens to be reviewing — it turns "looks good to me" into a repeatable set of questions that catch the issues that actually matter. The most useful checklists group checks into a few buckets and keep them short enough that reviewers actually use them. **Correctness** comes first: does the change do what the PR describes, are edge cases and error paths handled, and is there any leftover debug code? **Tests** are the next highest-leverage area — new behavior should be covered by meaningful tests (ones that would actually catch a regression, not just snapshots), and they should pass in CI. **Performance** checks catch the cheap-to-prevent, expensive-to-fix problems: N+1 queries, needless work in hot loops, and unbounded data handling. **Security** is non-negotiable for anything touching input, auth, or secrets — validate input, escape output, never commit credentials, and confirm authorization. Finally, **readability and docs**: clear names, sensible scope (no unrelated changes sneaking in), comments explaining the non-obvious "why," and updated docs/README for public-facing changes. A few practices make reviews better than any checklist alone: keep PRs small (large PRs get rubber-stamped), be specific and kind in comments, distinguish blocking issues from "nits," and end with an explicit decision (approve / approve-with-nits / request-changes) so the author knows exactly what is needed. Treat the checklist as a floor, not a ceiling — add project-specific checks (feature flags, analytics, migrations) and use judgment for anything it does not cover.
When to use it
- Reviewing a pull/merge request.
- Standardizing review quality across a team.
- Onboarding new reviewers with a shared baseline.
- Self-reviewing your own PR before requesting review.
What to include
- Reviewer, author, PR link, and a change summary.
- Correctness and error-handling checks.
- Test coverage and CI checks.
- Performance and security checks.
- Readability/docs checks, project-specific items, and an explicit decision.