Effective Code Review: Google’s Guidelines and Practical Implementation Strategies

Background

Code review is the practice of having others examine your code to ensure the overall health of the codebase improves over time. As the Chinese saying goes, "Three people walking together, there is always a teacher among them," and code review works the same way: external reviewers bring fresh perspectives and reduce the chance of mistakes.

Therefore, code review is the most important check before merging code into the main branch and a low‑cost way to discover software defects.

Despite its clear benefits, many teams struggle to execute code reviews effectively. Two main reasons are the time required for reviewers to understand the code (often needing the author to explain business context) and reviewers being overloaded, leading to superficial reviews.

Google’s Code Review Rules

When conducting a code review, Google recommends ensuring the following:

Code is thoughtfully designed.

The feature is useful to its users.

Any UI changes are sensible and look good.

All parallel programming is safe.

Code is no more complex than necessary.

Developers have not implemented things they may not need later.

Appropriate unit tests exist.

Tests are well‑designed.

Clear naming is used throughout.

Comments explain *why* rather than *what*.

Documentation is correct and complete.

The code follows the style guide.

Reviewers should examine each line in context, improve the code’s health, and commend good work.

Original source: https://google.github.io/eng-practices/review/reviewer/looking-for.html

Putting the Rules into Practice

To adopt effective code review, first establish a set of rules that suit your team, then let technical leaders promote them, and finally embed the rules into the pull‑request workflow through process controls and automation.

Process Controls

Avoid any code reaching the main branch without review.

Using Bitbucket as an example (GitHub and GitLab have similar settings).

Enable the "Prevent changes without a pull request" option in branch permission settings. You can add exceptions for specific users if needed. Prevent changes without a pull request

In the Merge Check settings, enable "Minimum approvals" (e.g., set the number of approvals to 1) so that at least one reviewer must approve before merging. Minimum approvals

Automated Checks

Validate builds and tests via CI pipelines.

Set up an automated build and test pipeline (e.g., Jenkins Multi‑branch pipeline) to run on every pull request.

Enable Bitbucket’s "Minimum successful builds" check to prevent merging code that fails the CI build. Minimum successful builds

Additional automation ideas: Analyze PR history to recommend reviewers. Use lint tools to enforce coding standards. Leverage REST APIs to enforce commit‑message conventions. Integrate SonarQube for quality‑gate checks.

Automation allows reviewers to focus on the substantive aspects of the code while routine checks are handled by tools.

Final Thoughts

The quality of code review correlates with a team’s technical culture and leadership. Teams of engineers who value craftsmanship will eagerly write and critique high‑quality code, whereas teams that ignore standards and chase short‑term metrics accumulate technical debt and produce poorer products.

If most engineers have a strong sense of taste, they will enjoy producing excellent code and finding defects.

Conversely, a lack of emphasis on standards leads to growing technical debt and deteriorating product quality.

Feel free to leave comments with your opinions or suggestions.