Code Review Checklist for Pull Requests

Correctness

0/5

Trace the change against the ticket or PR description, not just the diffA diff can be internally consistent and still solve the wrong problem.
Manually walk through at least one happy path and one failure pathReading code hides bugs that tracing an actual execution path reveals.
Check every edge case the function's own logic implies — empty input, zero, null, the last item in a loopThese are exactly the inputs authors stop testing once the main case works.
Verify error handling actually handles the error, not just catches and swallows itA silent catch block turns a debuggable failure into a mystery for whoever hits it next.
Confirm the change doesn't quietly alter behavior outside its stated scopeScope creep in a diff is where regressions in unrelated features come from.

0/5

Read function and variable names without the surrounding code and see if they still make senseIf a name needs the implementation to explain it, it's the wrong name.
Flag any function doing more than one job, even if each part is shortMixed responsibilities are what make later changes touch code they shouldn't.
Check that comments explain why, not what the code already saysA comment restating the next line goes stale the moment the code changes and the comment doesn't.
Look for duplicated logic that could reuse an existing helper or componentTwo copies of the same logic will drift the first time only one gets fixed.
Make sure the diff is scoped to one logical change, not bundled with unrelated cleanupBundled diffs hide the actual change and make a later revert an all-or-nothing bet.

0/4

Confirm new logic has a test that fails without the fix and passes with itA test that passes either way isn't testing the change at all.
Check that tests assert on behavior, not on implementation details like internal call countsImplementation-coupled tests break on harmless refactors and stop meaning anything.
Look for at least one test covering a failure or boundary condition, not only the happy pathHappy-path-only suites are the ones that pass right up until production proves them wrong.
Run the test suite locally or in CI rather than trusting a green checkmark aloneFlaky or skipped tests can show green without actually having run.

0/4

Verify user input is validated or sanitized before it reaches a query, shell command, or templateThis is the single check that stops injection-class bugs from shipping.
Check that new endpoints or actions enforce the same authorization as similar existing onesA new route is the easiest place to accidentally skip a permission check that everything else has.
Look for secrets, tokens, or credentials committed directly in the diffOnce a secret is in git history, rotating it is the only real fix — deleting the line isn't enough.
Confirm any new dependency is from a maintained package, not an unreviewed one-offUnmaintained dependencies are a common way vulnerabilities enter a codebase unnoticed.

0/4

Check for a database query or network call placed inside a loopN+1 calls are the most common performance regression a review can catch before it hits production.
Look for unnecessary re-renders, re-fetches, or recomputation on every callCheap-looking code run on every keystroke or render adds up under real usage.
Confirm large lists or datasets are paginated, virtualized, or streamed rather than loaded wholeCode that works on a 10-row test fixture can fall over on a 100,000-row production table.
Ask whether the change adds meaningful weight to a hot path — request size, bundle size, or query costSmall additions on a hot path compound in a way the same addition elsewhere wouldn't.