Code review checklist
A practical checklist for reviewing pull requests — correctness, readability, tests, security and performance, with the reasoning behind each check.
Last updated
Your ticks are saved on this device only — never uploaded, never synced.
Correctness
0/5Readability
0/5Tests
0/4Security
0/4Performance
0/4Questions
Why is correctness first?
Because it is the only category where being wrong ships a bug. Reviews that open on naming and formatting spend their attention budget before reaching the logic, which is the part a second pair of eyes is genuinely needed for.
How long should a review take?
Research on review effectiveness consistently finds defect detection falls sharply after about sixty minutes, and on changes larger than roughly four hundred lines. If a diff cannot be reviewed in an hour, the useful response is to ask for it to be split.
Should style comments be in a review at all?
Only what a formatter cannot settle. If a convention matters, encode it in a linter so it is enforced without a person spending review attention on it — and so it is not negotiated per pull request.
What if I do not understand the change?
Say so, and ask. Approving something you cannot follow is worse than blocking it, and the confusion is usually a signal about the code rather than about the reviewer.
Does every item apply to every change?
No. A dependency bump does not need a performance pass and a query change does. Working through categories that do not apply teaches people to skim the checklist, which costs you the ones that do.