Two engineers argued for twenty minutes about a variable name. The unhandled null case three lines down shipped anyway.
Review against whether a bug fails loudly, whether someone else can safely change it later, and whether it's easy to reason about, not naming taste.
code-reviewteam
Problem
Code review turns into a taste debate (naming, formatting, whether a ternary is “too clever”) while the actual risk in the PR goes unreviewed.
Why it happens
Taste is easy to have an opinion about and easy to argue in a comment thread. Real risk (does this fail loudly, can someone else change it safely in six months, what happens when this input is null) takes more effort to spot, so it quietly loses the time budget.
Better approach
Review against three questions instead of vibes:
- If this breaks, will it fail loudly or silently?
- Can someone unfamiliar with this code change it safely in six months?
- Can you reason about what this does without tracing five other files?
If a comment doesn’t relate to one of those, it’s a nice-to-have, not a blocker.
Example
A PR where the whole thread was about renaming data to userData, and nobody flagged that the function silently returned undefined instead of throwing when the lookup failed. That’s the bug that paged someone at 2am, not the variable name.