Code Review: Reading a Change You Did Not Write
Review reads a diff and asks whether it does what was intended, whether it breaks anything nearby, and whether the next person will understand it. The skill is separating the change that has to happen from the taste that does not.
What a learner can do afterwards
- Review a small change and separate correctness comments from preference comments
- Ask a question about a change instead of asserting what it should have been
- Spot a change that is right in itself but breaks a caller elsewhere
1 · Read
Review reads a diff and asks three questions. Does the change do what was intended. Does it break anything nearby. Will the next person understand it.
This crashes on empty input is a correctness comment. It names behaviour that must be fixed. I would rename this variable is a preference comment. It names taste that the author may keep.
Ask a question instead of asserting what the change should have been. What happens when the input is empty invites checking. Then look past the changed lines, because a change can be right in itself yet break a caller elsewhere.
On a twenty-line change, leave two comments that still matter if the author disagrees about style. Name the broken case or the confused caller. Skip the naming taste.
Judge the behaviour, ask instead of command, and check the callers the diff never shows.
2 · Watch
Take it off screen
Where it sits
Learn first
This opens up
Nothing builds on it yet.
8 questions wait behind this lesson, each with its answer explained. Every answer feeds the sky: stars light as they are learned, and dim when it is time to come back.