Code Review Best Practices for Healthy Teams
Why teams review code, how small changes and quick responses help, how to write respectful comments, and where checklists and automated checks fit in.
The Agile Coach · Last reviewed October 21, 2026 · 5 min read
In most software teams, a change does not go into the shared codebase until at least one other person has looked at it. This step, called code review, is one of the most common engineering practices in the industry and one of the most frequent sources of friction.
Done well, review catches problems early, spreads knowledge and keeps a codebase healthy over years. Done poorly, it becomes a bottleneck, a source of conflict or a rubber stamp. The difference is usually not the tool but the habits around it.
This guide draws heavily on Google's publicly available engineering practices documentation, which sets out how reviewers and authors are expected to work, and translates it into guidance any team can use.
What Code Review Is For
A code review is a request for another developer to read a proposed change and approve it or suggest improvements. Google's documentation calls each proposed change a CL, short for changelist; elsewhere you will hear pull request or merge request.
The purpose is broader than finding bugs. Reviews help make sure code is understandable to people other than its author, consistent with the rest of the system and well tested. They also spread knowledge: reviewers learn about parts of the system they did not write, and authors learn from reviewers' experience.
Google's guidance sets a clear standard: reviewers should generally favor approving a change once it definitely improves the overall code health of the system, even if it is not perfect. The goal is continuous improvement, not perfection. Holding every change to an ideal standard slows teams down without making the codebase much better.
Keep Changes Small
The single most effective thing an author can do is send small changes. Google's documentation lists the benefits: small changes are reviewed more quickly and more thoroughly, are less likely to introduce bugs, waste less effort if rejected, are easier to merge and easier to roll back.
It defines a small change as one self-contained change that addresses just one thing, including its related tests. It suggests that 100 lines is usually a reasonable size and 1,000 lines is usually too large, while leaving the final judgment to the reviewer. Spreading a change across many files also makes it harder to review.
This connects to continuous integration. Teams that integrate frequently naturally produce smaller changes, and smaller changes make frequent integration practical.
Respond Quickly
Slow reviews quietly damage a team. Work waits, authors context-switch, and pressure builds to approve things without proper attention. Google's guidance says one business day is the maximum time it should take to respond to a review request.
Responding does not mean finishing a long review instantly. It means not leaving a colleague waiting without an answer. Interestingly, the guidance notes that developers tend to complain less about strict reviews that are fast than about lenient reviews that are slow.
Review Etiquette
Review comments are written messages about someone's work, which makes tone important. Google's documentation offers practical principles:
- Comment on the code, never on the developer.
- Explain why you are suggesting a change, not only what to change.
- Balance pointing out problems with letting the author find the solution, which helps them learn.
- Label the weight of a comment, for example with "Nit" for minor polish, "Optional" or "Consider" for suggestions, and "FYI" for information that needs no action.
- Point out what is done well, not only what needs work.
A hypothetical contrast shows the difference. "Why would you do it this way?" can sound like an accusation. "This loop runs once per customer; could we look the data up once instead? It would avoid slowdowns with large accounts" explains the concern and invites discussion.
Authors have responsibilities too: describe what the change does and why, respond to every comment, and treat questions as a sign that the code may need to be clearer for future readers. The guidance points out that explanations written only in the review tool do not help the next person who reads the code.
Use a Checklist, Lightly
Checklists help reviewers stay consistent, especially new ones. Google's documentation suggests looking at design, functionality, complexity, tests, naming, comments, style and documentation. In plain terms, reviewers might ask:
- Does this change belong here, and does it fit the rest of the system?
- Does it do what the author intended, including in unusual cases?
- Could another developer understand it quickly?
- Are there tests, and would they fail if the code broke?
- Do names and comments explain purpose, especially why the code exists?
- Has related documentation been updated?
Google's guidance treats the team's style guide as the authority on required style rules. Where the guide is silent, reviewers are encouraged to favor consistency with the existing code rather than personal preference, which keeps reviews from turning into debates about taste.
Keep the list short and relevant to your team. A long checklist that people tick without thinking adds ceremony rather than value.
Let Automation Handle the Routine
Human attention is the scarcest resource in review. Anything a machine can check reliably should be checked by a machine before a person looks. That typically includes automated tests run by the continuous integration system, formatting tools, style checkers and security scanners.
When automation handles formatting and routine rules, reviewers can focus on design, clarity and correctness, the things only people can judge. It also removes a common source of petty disagreement, since nobody needs to argue about spacing when a tool enforces it.
Key takeaways
- Code review exists to keep the codebase healthy and to share knowledge, not just to catch bugs.
- Approve changes that clearly improve code health, even if they are not perfect.
- Keep changes small and respond to review requests within a business day.
- Write comments about the code, explain your reasoning and label their importance.
- Use a short checklist and let automated checks handle routine issues.
Sources
Spotted something out of date? Let us know.