Chapter 1 of 7 · 4 practices · 3 min · 3-question quiz
The standard for approving a change
Before looking at any code, a reviewer needs to know what bar a change has to clear. This chapter covers the core rule, what counts as a preference, and how to settle style and design arguments.
Start: Approve a change once it clearly improves the code, even if it is not perfect4 practices in this chapter
- 1Approve a change once it clearly improves the code, even if it is not perfectGoogle'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…
- 2Settle arguments with facts, the style guide and engineering principlesMany review arguments are really about taste. Google's guide sets an order of authority that removes most of them: Technical facts and data beat opinions and personal preferences; The style guide is…
- 3Reject changes the codebase does not need, even when the code is goodClean code can still be the wrong change. The guide notes that a reviewer can turn down a change that adds a feature the system does not want, even if the change is well designed.
- 4Teach through reviews, but mark lessons as optionalReviews are one of the best ways to share knowledge: a language feature, a better library function, a pattern used elsewhere in the codebase. Google's guide encourages these comments, with one…
Check yourself on this chapter
3 questions, right here once you are signed in. Your progress is saved as you read.