Code Review

A code review is a teammate reading your change before it merges. Done well, it catches bugs, spreads knowledge, and keeps the codebase consistent. Done poorly, it creates resentment and slows the team down.

What to Look For

When reviewing, work through the change in a rough order:

• Correctness — does the code do what the description claims? Are edge cases handled? Will it break under high load or with unusual input?
• Tests — is the new behavior covered? Do the tests actually exercise the change, not just the happy path?
• Readability — will someone understand this six months from now? Are names clear? Is anything unnecessarily clever?
• Architecture — does this fit the existing patterns in the codebase? Is there duplication that should be factored out?
• Security and performance — any unvalidated input, secrets in code, or N+1 queries?

Skip the things automated tools already catch — formatting, simple style — so you can focus on the things only a human can spot.

Comment Etiquette

Comments are easy to read as harsh because they lack tone. A few habits help:

• Ask, do not command. "What do you think about extracting this?" lands better than "Extract this."
• Be specific. "This loop scans the whole list on every iteration; could you build a set first?" beats "performance concern."
• Distinguish blocking from optional. Prefix optional suggestions with "nit:" or "non-blocking:" so the author knows they can ship without addressing them.
• Praise the good parts. Calling out a clean abstraction is part of the review too.

Automated Checks

Reviewers should not hunt for things a computer can find. Set up:

• A formatter (Prettier, Black, gofmt) so style debates disappear
• A linter (ESLint, ruff, clang-tidy) to catch suspicious patterns automatically
• A type checker if your language has one (mypy, TypeScript)
• CI that runs your tests on every push

The example shows the same idea in miniature: a small function that flags magic numbers, long lines, and stale TODOs.

Try It Yourself

• Add a check to the linter that flags any function over 30 lines
• Review one of your own old PRs and write three comments you wish someone had left
• Look at your team's last five reviews and count how many were nits vs blocking