Google Engineering Practices

What is in it

The site holds two documents. Google calls a change under review a "CL" (changelist), the equivalent of a pull request elsewhere.

The Code Reviewer's Guide covers:

• The standard of code review: when to approve.
• What to look for: design, functionality, complexity, tests, naming, comments, style, consistency and documentation.
• How to navigate a CL, the speed of code reviews, how to write review comments, and how to handle pushback.

The Change Author's Guide covers:

• Writing good CL descriptions.
• Keeping CLs small and how to split them.
• How to handle reviewer comments.

The content is licensed under CC BY 3.0. Its GitHub repository has about 23.3k stars and has been archived, so it is no longer updated, but the site remains available and the guidance has not aged.

The principle worth adopting

A reviewer should approve a change once it definitely improves the overall health of the codebase, even if it is not perfect. That single rule resolves most review conflict, because it replaces an unwinnable argument about ideal code with a decidable question about direction. Comments that are optional should be marked as such (the guide suggests a "Nit:" prefix), so authors know what blocks approval.

The parts authors need

Two sections repay close reading. "Small CLs" explains why reviewers review small changes faster and better, and how to split work. "Handling reviewer comments" covers feedback you disagree with: reviews turn tense in predictable ways, mostly from tone and from people defending a decision instead of explaining it.

How to use it on your team

• Read both guides once, whichever role you usually play.
• Agree as a team on a response time for reviews; the guide explains why speed matters more than people think.
• Adopt the "Nit:" convention and the "improves code health" standard explicitly.
• Write pull request descriptions following the author's guide: a short summary line, then what and why.

None of it depends on Google's scale or tooling. It works on a team of three.

Common questions

Is it outdated since the repo is archived? No. It describes principles, not tools, and remains widely referenced.

What is a CL? Google's term for a change under review, equivalent to a pull request.

Is it useful for students? Yes, especially before a first internship, where code review is often the biggest adjustment.

Best for: anyone who reviews code or has code reviewed, and especially teams whose reviews have become a source of friction.