Seven Code Review Comments I No Longer Leave
After six years and roughly 4,000 reviews, I quietly retired some of my favourite nitpicks. Here is the list and the reasons.
I counted once. Across two jobs I have left something like 4,000 code reviews. Looking back at old ones is uncomfortable. A lot of my comments were technically correct and practically useless.
Here are seven I have stopped leaving, and what I do instead.
1. Formatting opinions
If the linter and formatter allow it, I allow it. Arguing about trailing commas in review means our tooling is incomplete. I fix the config, not the PR.
2. Could you rename this?
Unless the name is actively misleading, I let it go. userList versus users is not worth a round trip. A name that says isActive but actually checks billing status, though, gets a comment every time.
3. This could be a one-liner
Compressing a readable five-line if into a nested ternary is not an improvement. I used to suggest these to look clever. Now I only comment when the long version hides a bug.
4. Have you considered a different approach?
This comment, with no specifics, is a trap. It forces the author to guess what I am thinking. If I have a concrete alternative, I write it out, including what it costs. If I do not, I keep quiet.
5. Nit: (fifteen times)
A PR with fifteen nits feels like a failing grade even if every nit is optional. Now I pick the two that matter most and drop the rest. Sometimes I fix small things myself in a follow-up.
6. Questions I could answer by reading
Asking why is this here? when the answer is two files away wastes the author's time and signals I did not try. I read first, then ask about whatever is still genuinely unclear.
7. Approval with silence
This is the opposite problem. A bare approval tells the author nothing. Now I always leave at least one sentence about what I checked: ran it locally, tested the empty cart case, looks good. It takes ten seconds and builds a lot of trust.
What I comment on now
My reviews are shorter, and they focus on a small list:
- Correctness, especially edge cases like empty input, nulls and time zones.
- Anything that changes a public API or database schema.
- Missing tests for logic that is easy to break later.
- Security issues, always, even small ones.
- Code I genuinely cannot understand after a real effort.
I also label every comment as blocking or non-blocking. That one habit cut our average review cycle from about two days to under one, because authors stopped waiting for permission to ignore suggestions.
Review the change, not the person, and not the version of it you would have written.
Good review is not about catching everything. It is about catching the things that would hurt, and getting out of the way for everything else.
Cover: Photo by Compagnons on Unsplash.
