Ready-to-use resource
Copied 0 timesUse when reviewing a pull request or code diff before approving it.
Review this code change systematically, not just for whether it "looks right": 1. Correctness: does the logic actually do what the PR description claims? Trace through at least one non-trivial input by hand. 2. Tests: are the changed code paths covered? A change with no new/updated tests is a flag, not an automatic rejection — ask why. 3. Edge cases: empty input, null/undefined, the boundary values (0, -1, max), and concurrent access if the code touches shared state. 4. Security: user input reaching a query, shell command, file path, or template without validation/escaping; secrets or credentials in the diff; newly-added dependencies from unfamiliar sources. 5. Readability: could someone unfamiliar with this change understand it from the code and its names alone, without the PR description? 6. Scope: does the diff do only what it claims, or does it quietly refactor/reformat unrelated code, making the real change harder to see? Report findings as a list, most important first, each with: what's wrong, why it matters, and a concrete suggested fix — not just "this looks off." If nothing significant is wrong, say so plainly instead of inventing nitpicks to seem thorough.
Advertisement
Before you begin
You're opening Code Review Checklist. Here's the quickest way to get a useful result.