How to Excel in Code Review

How to Excel in Code Review

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

As the name suggests, code review is a process where one or more developers examine code written by another developer (the author) to ensure:

the code has no errors or issues.

it meets all quality requirements and standards.

the code passes the intended tests.

after merging, it keeps the codebase health better.

This is why code review is a critical part of software development. Reviewers act as codebase custodians, deciding whether code is ready to become part of the repository and go into production.

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

Here is the list of items to keep in mind when looking at a change list.

Review Standards

1. The code improves the overall health of the system

Every change list (Pull Request) should improve the overall health of the system. The idea is that small improvements accumulate, so each merge makes the software or codebase healthier.

2. Fast code review, response and feedback

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

"The key here is that 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 completed; however, a working day is the maximum time needed to respond to a pull request. Expect the change list to receive multiple rounds of partial/full 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 documents are the absolute authority during a review. For example, you can refer to the style guide to keep tabs versus spaces consistent.

5. Resolve review conflicts

Resolve conflicts by following the best practices agreed in the style guide and coding standards, 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 it in the comment and let the author decide whether to address or ignore it. As a reviewer, you can at least suggest that the change list stay consistent with the rest of the codebase even without a style guide.

6. Demonstrate UI changes as part of the review

If the change list modifies the user interface, a demo must be performed in addition to code inspection to ensure the visual appearance matches expectations and mockups.

For frontend change lists, it is always recommended to conduct a demo/run‑through, or ensure the change list includes necessary UI automation tests to verify added/updated functionality.

7. Ensure the review is accompanied by all tests

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

Emergencies may be critical bugs or security vulnerabilities that need a quick fix, with tests added later. In such cases, create appropriate tickets and ensure ownership so that after a hot‑fix or deployment the necessary tests are added.

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

8. Stay focused and do not disturb yourself while reviewing

If you are in a period of focused work, do not disturb yourself, as it may take a long time to get back to the flow. In other words, the cost of interrupting a focused developer is higher than making the developer wait for a review. Conduct the review after planned breaks (e.g., lunch, coffee).

It is not expected to finish and merge the entire review process in a single day. The important thing is to give the author quick feedback. For example, you may not be able to perform a full review, but you can quickly point out items for further investigation, greatly reducing frustration during the review.

9. Review everything, make no assumptions

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

Make sure you understand the code you are reviewing. If not, ask for clarification or request a walkthrough/explanation. If part of the code is beyond your review competence, ensure other qualified developers can review those parts.

10. Keep the big picture in mind when reviewing code

Viewing changes in a broader context is helpful. For example, a file changed with four new lines. Do not only look at those four lines; instead, consider the whole file and assess whether the new code degrades existing quality or creates refactoring candidates.

If you inspect such small additions outside the function/class context, over time you will inherit a class that is unmaintainable, overly complex, hard to test, and difficult to extend or refactor.

Remember that over time, many small improvements lead to a high‑quality product with minimal defects, while small degradations or technical debt accumulate and make the product hard to maintain and scale.

11. Recognize and encourage good work during the review

If you see something good in a change list, don’t forget to shout out the author’s excellent work and encourage them. Code review should not only find bugs but also motivate and guide developers on what they did well.

12. Be careful, respectful, friendly, and clear in the review

It is essential to be kind, clear, polite, and respectful during the review, while also being very clear and helpful to the author. When commenting on code, focus on the code, not the developer.

13. Explain your review comments and keep scope in mind

Whenever a review comment suggests an alternative or flags an issue, it is crucial to explain the reason and provide examples based on your knowledge and experience to help the developer understand how your suggestion improves code quality.

When suggesting fixes or changes, strike a balance in guiding the author—offer guidance, explanations, tips, or suggestions rather than delivering a complete solution.

Thank you for reading, and I hope you enjoyed this article. If you have any feedback or suggestions, please reply in the public account.