How to Excel at Code Reviews

How to Excel at Code Reviews

In this article we briefly introduce 13 code‑review standards that can greatly improve software health and keep developers happy.

Code review is a process where one or more developers examine the code written by another developer (the author) to ensure that the code has no errors, meets all quality requirements, passes the intended tests, and, after merging, improves the overall health of the codebase.

Google is known for its effective code‑review standards, which highlight key points to remember when reviewing code. At Google, the main goal of code review is to continuously improve the overall health of the codebase over time.

Review Standards

1. The code improves the overall health of the system

Every pull request should improve the system’s overall health. The idea is that small improvements accumulate, so each merge makes the software or codebase healthier.

2. Fast code review, response and feedback

Do not delay pushing (merging) better code. Do not expect code to be perfect. If it can improve the system’s health, push it.

“The key here is there is no ‘perfect’ code, only better code.”

If you are not in the middle of a high‑priority task, review the code as soon as it is finished; otherwise, a working day is the maximum time to respond to a pull request. Expect multiple rounds of partial/complete review within a day.

3. Educate and inspire during the review

Share knowledge and experience as much as possible, providing guidance during the review.

4. Follow standards when reviewing code

Always remember that coding standards and style guides are the absolute authority during a review. For example, refer to the coding conventions to keep consistency between tabs and spaces.

5. Resolve review conflicts

Resolve conflicts by following agreed‑upon best practices in the style guide and by seeking advice from more experienced people in the product domain. The handling differs based on severity.

If your comment is optional or minor, note that in the comment and let the author decide whether to address it. As a reviewer, you should at least suggest changes that keep the pull request consistent with the rest of the codebase when no style guide exists.

6. Demonstrate UI changes as part of the review

If a pull request changes the user interface, a demonstration is required in addition to code inspection to ensure the appearance matches expectations and mockups.

For front‑end pull requests, it is always recommended to include a demo/run‑through or ensure the PR includes necessary UI automation tests to verify added/updated functionality.

7. Ensure the review is accompanied by all tests

Unless there is an emergency, a pull request should be accompanied by all necessary tests such as unit, integration, and end‑to‑end tests.

Emergencies may be critical bugs or security vulnerabilities that need a hot‑fix; in such cases, create appropriate tickets and ensure ownership for post‑fix verification.

There is never a sufficient reason to skip testing. If time constraints make some goals risky, the solution is to scope the deliverable, not to omit tests.

8. Stay focused and avoid interruptions while reviewing

If you are in a period of focused work, do not interrupt yourself for a review, as it may take a long time to regain focus. Conduct reviews after scheduled breaks (e.g., lunch, coffee).

It is not expected to finish and merge the entire review in one day. Providing quick feedback, even if not a full review, greatly reduces frustration.

9. Review everything, make no assumptions

Examine every line assigned to you. Do not assume anything about manually written classes or methods; ensure you understand what the code does.

If you do not understand the code, ask for clarification or a walkthrough. If part of the code is beyond your expertise, ensure another qualified developer can review that part.

10. Keep the big picture in mind when reviewing

Consider the broader context rather than just isolated lines. For example, adding four lines in a file should be examined in the context of the whole file to see if they degrade existing quality or create refactoring candidates.

Neglecting context leads to an unmaintainable, overly complex, and hard‑to‑test codebase over time.

Remember that small improvements accumulate into high‑quality products, while minor degradations accumulate into technical debt.

11. Recognize and encourage good work during the review

When you see something good in a pull request, acknowledge the author’s excellent work and encourage them. Reviews should not only find bugs but also highlight and motivate quality contributions.

12. Be courteous, respectful, kind, and clear

During the review, be kind, clear, polite, and respectful, while being helpful to the author. Comment on the code, not the developer.

13. Explain your review comments and stay within scope

When you suggest alternatives or raise issues, explain the reasons and provide examples from your experience to help the developer understand how your suggestion improves code quality.

When recommending fixes, strike a balance between guidance and providing a full solution; offering hints or suggestions is often more valuable than a complete answer.

Thank you for reading; we hope you enjoyed the article. Feel free to leave feedback in the public account.