Code Review

Code review has two jobs: catch defects, and spread knowledge. Most bad reviews fail at both by optimising for the wrong things.

Review in priority order. Correctness and security first. Then design and whether this is the right change at all. Then maintainability. Style last, and ideally never — if you are commenting on formatting, your linter is missing a rule and you are spending human attention on something a machine should own.

The most valuable comment is usually a question. "What happens if this list is empty?" invites the author to check and preserves the possibility that you have missed context. "This breaks on empty lists" is worse when you are wrong and no better when you are right.

Distinguish blocking from non-blocking. Prefix the ones that are not: "nit:", "optional:", "future:". Without that, authors treat every comment as a gate and reviews spiral. A reviewer who never says "this is fine, ship it" is teaching people to stop asking.

Small PRs get real reviews. A 50-line change gets scrutinised; a 2,000-line change gets an approval and a prayer. Defect detection falls off a cliff with size, so the highest-leverage review comment is often "can this be split?" — said before the work is done, not after.

Approve with comments when nothing blocks. Holding an approval hostage to a preference is how review queues become the constraint on a team's delivery.

On the receiving end: assume good intent, ask when unclear, and push back with reasons when you disagree. A review comment is an opinion with context you may not have — and so is your code.