Code review: reading a change you did not write
In a code review, you read a diff and ask whether the change does what was intended, whether it breaks anything nearby, and whether the next person will understand it. The skill is separating required changes from personal taste.
What a learner can do afterwards
- Review a small change and separate correctness comments from preference comments
- Ask a specific question when behavior is uncertain, and support a verified defect with evidence
- Spot a change that is right in itself but breaks a caller elsewhere
1 · Read
A diff shows lines added and removed by a change. Compare it with the required behavior. Check what the changed code does, whether code using it still works, and whether the next reader can understand it. Tests and callers outside the diff can reveal problems the changed lines alone do not show.
A Python function must return None for an empty list. Its changed body returns xs[0], which means the first list element. An empty list has no first element, so Python raises IndexError. A review comment should name that input, the required None result and the observed exception.
Separate required behavior from personal preference. A private variable name you dislike may be optional if it is clear and follows team rules. Names are not always taste: renaming a function used elsewhere can break callers, and unclear names can hide meaning. Explain the effect or agreed rule behind a requested change.
When uncertain, ask a specific question such as: What happens with empty input? When you have reproduced a defect, report the evidence directly. Give the input, expected behavior and observed behavior, and point to the relevant code. Use a test that distinguishes the required result from the observed one.
A function now returns None when there are no results. A caller still tries to count the returned list. Counting None fails. The function may meet its new requirement while the caller needs an update. Inspect code that uses the function and tests of that interaction.
Prioritize verified behavior problems over optional preferences. Confirm that a claimed fix meets its requirement, then check for new failures and changes outside the request. If the request says to preserve exact prices, rounding prices needs review even when the requested bug fix passes its test. Support comments with the requirement and evidence.
Review against requirements, inspect callers and test. Ask when uncertain; report verified defects with evidence. Separate preferences from effects.
Original teaching, questions and flashcards about checking software changes against requirements, written for this dataset.
The reading Leave a check the author can repeat was written for this dataset.
More to read
Leave a check the author can repeat
Start a review by finding the behavior the change promises. Keep that requirement beside the diff as you read. For each concern, identify the input or caller that would reveal it.
Separate what you observed from what you still need to check. If a test produces an exception where the requirement calls for a value, report both results and the input. If you have not tried the case, ask a focused question. Do not present a possible failure as one you have reproduced.
Then follow the changed function's result into the code that uses it. A new return value can satisfy the function's own requirement while breaking an older caller. Tests of the interaction can reveal that mismatch.
Before sending the review, distinguish required repairs from personal preferences. Explain the effect behind a requested rename or formatting change. A name used by callers can affect behavior; a clear private name that follows team rules may only differ from your preference. Give the author enough detail to repeat the check and understand why it matters.
2 · Watch
Take it off screen
Where it sits
Learn first
Optional connections
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.