Google's code review standard says reviewers should favor approving a change once it definitely improves the overall health of the codebase, even if it is not perfect. That keeps reviews moving. Security defects are the main case where the same guide says do not approve.
The senior principle
The guide calls this its senior principle: "favor approving a CL once it is in a state where it definitely improves the overall code health of the system." It also says to seek continuous improvement rather than perfection.
For teams that worry reviews are slow or personal, this is a useful brake. Style disagreements, naming taste and minor structure do not need to hold a pull request.
Marking the optional
The guide recommends prefixing minor, non-essential comments with "Nit:" so authors know they can ignore them. For security reviews, borrow the idea and make severity explicit.
- Blocker: this must change before merge, and why.
- Suggestion: worth doing, not required.
- Question: I do not understand this, please explain.
Where it stops
The same page states that nothing in it justifies checking in changes that clearly worsen the overall code health. Emergencies are the stated exception. A change that adds an injection path, removes an authorization check, or introduces a secret in code is not a net improvement, whatever else it fixes.
Notice the wording is about code health, not specifically security. The page does not give a security rule. What it gives is a way to argue: facts and data override personal preference, and design points must rest on engineering principles.
Using facts
"I do not like this" does not block a merge. "This route skips the permission check that the other routes call" does. State the concrete risk, point to the line, and show a failing test when you can.
Conflict
The guide says to reach consensus, then talk face to face or on video, then escalate to a lead or maintainer. It adds: "Don't let a CL sit around because the author and the reviewer can't come to an agreement." Write down the decision in the pull request.
Specialists
The guide's list of review concerns says to get a qualified reviewer for specialized areas such as privacy, security and concurrency. Code owners are the mechanism for that on GitHub. See requiring owner review on sensitive paths.
A free scan of your dependencies is available at gold.safeguard.sh/scan.
Putting it in your team norms
A short written norm helps new reviewers. Something like: approve when the change improves the code and has no blockers. Mark preferences as optional. Block on correctness, security and clear harm to maintainability, and say why.
Review the norm after a few months. If authors feel blocked on small things, tighten the optional label. If real problems are slipping through, raise the bar for sensitive paths and make sure the right owners are asked.
Quick check
Does approving imperfect code lower security?
Not if the imperfection is style or taste. The guide still says not to approve changes that clearly worsen code health, and a new security flaw does that.
Sources
- Google Engineering Practices: the standard of code review
- Google Engineering Practices: what to look for
Last reviewed: 19 October 2026.
