The order I review a pull request in
Most code review comments are about the wrong things. Naming, formatting, a missing semicolon — the parts a linter could have caught.
Here's the order I actually review a pull request in.
1. Does it do what the ticket asked — and only that?
Before reading a single line, I check the scope. A PR that fixes the bug and also "tidies up" three unrelated files is really four PRs, and the risky change is usually hiding in the tidy-up.
2. What happens when it fails?
The happy path is the part the author already tested. I go straight to the edges: the empty list, the timeout, the null that "can't happen", the second click on the submit button. That's where production bugs live.
3. Where does the data come from — and is it trusted?
Anything crossing a boundary — user input, an API response, a query param — should be validated where it enters, not deep inside the logic. If I can't point to where that happens, that's my first comment.
4. Would a test have caught this?
Not "is there a test". Would a test fail if this change were reverted? A test that passes either way is decoration.
5. Will the next person understand it?
Naming and structure matter — but they come last, not first. By this point I know what the code does, so I can tell whether a name is misleading or just not how I'd have written it. Only the first one deserves a comment.
The honest nuance: none of this works on a 2,000-line pull request. Past a certain size every review turns into "LGTM" — not because people are lazy, but because nobody can hold that much in their head. The cheapest review improvement is a smaller PR.
If a tool can catch it, a human shouldn't be commenting on it. Save your reviews for what only a person can see.
What's the first thing you look at when you open a pull request?