Chapter 09 Flashcards — Code Review
What are the three distinct approval gates required to submit a CL at Google?
?
LGTM (correctness): granted by any reviewer familiar with the code, verifying the change is correct and well-designed. Owner approval: granted by a designated code owner, verifying the change is appropriate for the codebase’s direction. Readability approval: granted by an engineer certified in the language’s readability process, verifying the change follows Google’s idiomatic style. All three must be obtained before submission; they cannot substitute for one another.
What is a Change List (CL)?
?
Google’s term for a unit of code change submitted for review — roughly equivalent to a pull request in other systems. A CL goes through the full review cycle: automated checks, human review, comment iteration, and final approvals before being merged.
What does LGTM stand for and what does it certify?
?
Looks Good To Me. An LGTM signals that the reviewer has examined the change and is satisfied that it is correct, well-designed, and does what it claims. At Google, LGTM is only one of three required approvals — it verifies correctness but does not substitute for owner or readability approval.
What is readability approval and why does a separate process exist for it?
?
Readability approval is granted only by engineers who have passed Google’s language-specific readability certification — a formal process demonstrating mastery of idiomatic style for a given language. It exists separately because an engineer can write correct, well-designed code that still deviates from the team’s style conventions; readability review ensures the codebase remains stylistically consistent at scale across thousands of contributors.
What is code ownership in the context of Google’s review process?
?
Every piece of code has designated owners — engineers responsible for the quality and health of that code. Owner approval is required before a CL touching their code can be submitted. This ensures changes are consistent with the codebase’s intended direction, not just locally correct. Ownership distributes accountability without creating single points of failure.
Why does Google’s three-gate approval system have three separate gates rather than one?
?
Because each gate checks a distinct quality property requiring different expertise. A correctness reviewer may miss idiomatic style violations; a readability reviewer may approve clean code that is architecturally wrong for the module; a code owner may approve a change through familiarity without scrutinizing correctness. The separation mirrors good software design: each gate checks exactly one class of property, and their combination provides comprehensive coverage.
Name the six distinct benefits of code review identified in Chapter 9.
?
- Code correctness — second pair of eyes catches bugs, logic errors, and edge cases. 2. Comprehension and legibility — reviewers proxy future readers, surfacing opaque code. 3. Code consistency — review enforces naming, error handling, and structural norms across many contributors. 4. Psychological and cultural benefits — expectation of review raises author bar and distributes code ownership psychologically. 5. Knowledge sharing — reviewers learn unfamiliar code; authors learn patterns they were unaware of. 6. Audit trail — permanent record of what was changed, by whom, and why.
How does code review improve code legibility even when the reviewer finds no bugs?
?
A reviewer who must understand code in order to review it is a proxy for future readers. If a reviewer cannot understand what a function does, neither can the engineer who inherits the code later. Code review forces authors to write code legible to someone other than themselves — surfacing unclear assumptions, missing documentation, and opaque naming choices that seemed obvious to the author.
How does code review create “psychological safety” around code quality?
?
The expectation that code will be reviewed raises the author’s bar before submission — authors write cleaner, better-documented code knowing it will be examined. When reviewers approve a change, they share responsibility for it, distributing code ownership psychologically across the team. This creates a culture where quality is a shared norm rather than an individual virtue.
How does code review serve as a knowledge-sharing mechanism?
?
Code review is a passive knowledge distribution channel: reviewers encounter parts of the codebase they might not otherwise see; authors learn about libraries, patterns, and idioms through reviewer suggestions. Over time, it reduces knowledge concentration in individuals and spreads it across the team. In mature cultures, code review is a primary channel through which junior engineers learn the codebase and the team’s reasoning.
What is the single most impactful practice for efficient code review?
?
Writing small CLs. Large CLs receive superficial reviews because reviewers cannot hold the entire change in working memory; small CLs receive thorough reviews. A CL should do one thing — if a change does two separable things, it should be two CLs. Benefits: reviewers complete reviews quickly (reducing author wait time), bugs in small CLs are easier to identify and revert, and the change history remains navigable.
What should a good CL description include?
?
A good CL description explains: What the change does (in the first line — becomes the commit headline), Why the change was made (what problem it solves or requirement it satisfies), and How the design decisions were made (when non-obvious). It allows reviewers to orient themselves before reading code and allows future engineers to understand the change’s intent when they encounter it in git history.
Why should reviewer lists be kept small?
?
Larger reviewer lists produce worse reviews due to diffusion of responsibility — each reviewer assumes others will catch issues they miss. The result is multiple superficial reviews rather than one thorough review. Google’s guidance: one or two reviewers is almost always sufficient. Exceptions include security-sensitive code, cross-team impact CLs, or changes requiring specialized domain expertise.
What is the principle behind automating code review checks?
?
Any check that does not require human judgment should be automated. Style enforcement, import ordering, dead code detection, and coverage thresholds should all run before human reviewers see the code. Human reviewers are expensive, slow, and inconsistent; automated tools are fast, cheap, and perfectly consistent. If a reviewer finds themselves leaving the same comment repeatedly, that is a signal the check should be automated.
What distinguishes a greenfield review from other types of code review?
?
A greenfield review examines code for a new project or major feature with no predecessors. It is the most demanding type because there are no existing patterns to compare against, design decisions are being made for the first time, and mistakes propagate through all future code built on that foundation. Greenfield reviews function as design reviews as much as code reviews and benefit from involving senior engineers early.
What are the key review concerns for a behavioral change CL?
?
A behavioral change modifies what existing code does. Review focuses on: correctness (does it do what the CL description says?), test coverage (are there tests verifying the new behavior, and are old tests updated?), and impact analysis (what other code may be affected by this change?). Behavioral change CLs are the most common type and the most likely to introduce bugs — reviewers should be skeptical and thorough.
What makes bug fix CLs particularly tricky to review?
?
Reviewers must verify the fix addresses the root cause, not just a symptom. A common mistake is a fix that makes the bug less visible without eliminating it. The key review question: “Does this fix prevent the condition that caused the bug, or does it only handle the bug’s effects?” Rollback CLs also deserve careful review despite time pressure — a poorly considered rollback can reintroduce bugs that the reverted change was fixing.
What best practice applies to refactoring CLs specifically?
?
Keep refactoring and behavioral changes in separate CLs. A refactoring CL should leave behavior identical — if tests pass before and after, the refactoring is likely safe. Mixing refactoring with behavior changes makes it impossible to verify either independently. Use automated refactoring tools where available. Rely on the test suite as the primary correctness check for refactorings.
What are Large-Scale Changes (LSCs) and how do they differ from normal CLs?
?
Large-Scale Changes are automated changes made across tens of thousands of files simultaneously — e.g., updating a deprecated API across the entire codebase. They use Google’s Rosie infrastructure and have their own review process because the scale makes individual CL review impractical. LSCs are distinct from normal CLs in that they are generated by tools rather than written by humans and require special tooling to review and submit safely.
What is the rubber-stamping anti-pattern in code review?
?
Rubber-stamping is approving a CL without actually reading it — giving LGTM because the author is trusted, the reviewer is busy, or the CL is large and daunting. It is the most dangerous anti-pattern because it creates the appearance of oversight while providing none of code review’s actual quality guarantees. The review record shows approvals were given, but no real review occurred.
What is wrong with a reviewer spending significant time on style nitpicking?
?
Style enforcement should be automated. A reviewer spending time on style is not spending time on design and correctness — the areas where human judgment is actually needed. If style comments appear in a review, they should be framed as non-blocking suggestions (“nit:”) rather than required changes. Repeated style comments are a signal that the check should be added to automated tooling.
What is the “blocking on opinion” anti-pattern?
?
A reviewer blocks submission of a correct, well-designed CL because they would have made a different but equally valid implementation choice. Code review is not a veto mechanism for stylistic preferences — if a change is correct and consistent with the codebase, it should be approved even if the reviewer would have done it differently. Reviewers may express their preferred approach as a suggestion, but must not block on it.
What are the author’s obligations in the code review process?
?
Authors must: write a clear CL description explaining what and why; keep changes small and focused; run automated checks before requesting review; respond to all comments (even if disagreeing, with reasoning); assume good intent in reviewer feedback; address or escalate disagreements rather than allowing them to fester. Authors should not disappear mid-review or treat reviewer feedback as an attack on their competence.
What obligations do reviewers have toward authors?
?
Reviewers must: actually read the CL before approving; direct feedback at the code, not the author; prioritize correctness and design over style; frame style comments as non-blocking (“nit:”); explain the reasoning behind change requests (not just what to change, but why); complete reviews promptly to avoid leaving authors blocked; not block on personal preference when the change is correct.
How should disagreements between author and reviewer be handled?
?
Both parties should attempt to reach consensus through explanation and reasoning — the author explains their intent, the reviewer explains their concern, and both consider whether there is a better approach that addresses both. If consensus cannot be reached, the disagreement should be escalated (to a code owner, a senior engineer, or a style arbiter) rather than allowed to block progress or fester. Disagreement is normal; intractable conflict is a process failure.
What is the relationship between code review and automated testing?
?
Code review and testing are complementary, not substitutes. Automated tests provide stronger correctness guarantees for a broader range of inputs; code review catches what tests don’t — incorrect assumptions, missing error handling, subtle logic errors that pass existing tests, and design flaws that make future bugs more likely. Neither replaces the other. Code review should not be a substitute for writing tests, and tests should not be a substitute for getting code reviewed.
Why does code review add friction, and why is that friction accepted at Google?
?
Code review adds latency to development — every change must wait for reviewer availability, iterate on feedback, and collect approvals before submission. The authors accept this friction as a deliberate trade-off: the friction of review produces a codebase that remains comprehensible, consistent, and maintainable at scale over time. The goal is not to eliminate friction but to make review efficient — minimizing unnecessary friction while preserving the friction that produces real value.
Total Cards: 27
Review Time: ~22 minutes
Priority: HIGH
Last Updated: 2026-06-02