Chapter 1 · Practice 1 of 4
Approve a change once it clearly improves the code, even if it is not perfect
Why it matters
Google's guide states the core rule plainly: reviewers should favour approving a change once it is in a state where it definitely improves the overall code health of the system, even if the change is not perfect.
Two pressures pull against each other in every review:
- Developers need to make progress. If every change is held until it is perfect, nobody ships, and people stop sending improvements.
- The codebase must not get worse. Each small shortcut adds up, and code health decays one approved change at a time.
The rule balances both. There is no perfect code, only better code. Ask for improvements that matter, point out polish as optional, and approve once the change leaves the codebase better than it was.
The guide also says the opposite clearly: a reviewer should never approve a change that makes code health worse, except in a real emergency.
Do
- Ask yourself: is the codebase better with this change than without it?
Avoid
- Holding a change for polish that does not affect correctness or maintainability
- Approving a change that clearly makes the code harder to maintain