Chapter 2 of 7 · 6 practices · 5 min · 4-question quiz
What to look for in a review
A checklist of what matters most, in roughly the order Google's guide gives it: design, functionality, complexity and tests first, then naming, comments, style and documentation.
Start: Start with design: does this change belong here and fit the system?6 practices in this chapter
- 1Start with design: does this change belong here and fit the system?Google's guide says the most important thing to cover in a review is the overall design of the change. A perfectly written function in the wrong place still makes the system harder to work with.
- 2Check that the change does what the author intended, including edge casesAsk whether the change does what the author meant it to do, and whether that is good for its users: both end users and the developers who will call this code.
- 3Push back on code that is more complex than it needs to beGoogle's guide gives a useful definition: "too complex" usually means it cannot be understood quickly by code readers. It also means developers are likely to introduce bugs when they change it.
- 4Review the tests and ask whether they would fail if the code brokeChanges should usually come with tests in the same change: unit, integration or end-to-end, as appropriate. But the existence of tests is not enough.
- 5Check names, comments and documentation explain the code to the next readerThe rest of the review is about whether the next developer can understand and change this code. If the code is so complex that it needs a comment to explain what it does, the guide suggests making…
- 6Read every line you were asked to review, in the context of the whole fileThe guide asks reviewers to look at every line of human written code they have been assigned. Data files, generated code and large data structures can be scanned, but logic deserves careful reading…
Check yourself on this chapter
4 questions, right here once you are signed in. Your progress is saved as you read.