The Essence of Google-Style Code Review: A Culture of 'Improvement' Over 'Perfection'

Source: Dev.to

Introduction

For engineers, code reviews occupy a significant portion of daily work. Many struggle with questions like, “How granular should I get?”, “Where is the line between personal preference and a bug?”, or “Why is the review process stalling our development?”

Google’s Engineering Practices documentation provides clear, battle‑tested answers to these issues. This article explains the Code Review Standards practiced by one of the world’s top engineering organizations, adapted for common development workflows such as GitHub.

Note: At Google a Pull Request (PR) is called a CL (Change List). This article uses PR/CL interchangeably for clarity.

Google defines the purpose of code review with a single, clear mission:

“The primary purpose of code review is to ensure that the overall code health of Google’s codebase improves over time.”

The Standard of Code Review

The key takeaway is that Google is not seeking “perfect code.”
If a change is not perfect but better than the current state, it should be approved. Reviewers may leave comments for future improvement, but as long as the change does not degrade code health, they can grant LGTM (Looks Good To Me). This pragmatic compromise maximizes development speed.

Review Priorities

Reviewers should evaluate code based on the following priorities, not merely skim it:

1. Design – Is the overall architecture sound and well‑integrated?
2. Functionality – Does it behave as the author intended and provide value to the user?
3. Complexity – Is the code simple? Are there “clever” parts that others won’t understand?
4. Tests – Are there correct, maintainable unit tests?
5. Naming – Are names clear and descriptive?
6. Comments – Do comments explain why something is done rather than just what is done?

Reference: What to look for in a code review (Google guidelines)

Personal Preferences

Google’s guidelines state that for personal preferences without a technical basis, the reviewer should defer to the author’s judgment. Reviewers should never impose their own coding style on others.

Speed of Review

Google places extreme importance on review speed because delays decrease the productivity of the entire team exponentially.

The One‑Business‑Day Rule

• Reviewers should aim to provide their first response within one business day (ideally by the following morning).

Interrupt vs. Focus

• You don’t need to break deep focus to respond immediately. Treat reviews as a top priority during natural breaks (e.g., after a task or returning from lunch).

Cost of “Slow Reviews”

• The longer a review takes, the more the author forgets context, leading to high context‑switching costs during the fix phase.

Reference: Speed of Code Reviews (Google guidelines)

How to Write Code Review Comments

• Collaboration, not criticism: Review the code, not the person.
  • Instead of “You wrote this poorly,” say “This function feels complex because …”.
• Provide the “why”: Explain why a change is needed (e.g., performance, future extensibility) rather than just demanding a fix.
• Nit (Nitpick): Use the Nit: label for minor suggestions that are optional but nice to have. This reduces psychological burden on the author.

Reference: How to write code review comments (Google guidelines)

Cultural Principles

• Reject perfectionism: Approve changes that improve the codebase, even if they aren’t perfect.
• Balance speed and quality: Respond within one business day while maintaining thoroughness.
• Respect and mentorship: Treat reviews as an opportunity to mentor and grow together.

By adopting these practices, teams can eliminate the frustration of stalled development and build a culture where everyone contributes to a healthier codebase.