--- title: "Code review: reading a change you did not write" description: "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" canonical: https://lightmysky.com/learn/computing/code-review-reading-a-change-you-did-not-write-mt_Hhe1Ou709s source: https://lightmysky.com/learn/computing/code-review-reading-a-change-you-did-not-write-mt_Hhe1Ou709s.md retrieved: 2026-11-12 --- > **Agent view.** This is the Markdown twin of the page, for tools and assistants. > When to use this site, and the call that answers each job: https://lightmysky.com/agent-instructions.md > API description (OpenAPI 3.1): https://lightmysky.com/openapi.json · Authentication: https://lightmysky.com/auth.md > Pricing: https://lightmysky.com/pricing.md · Catalog: https://lightmysky.com/llms.txt · Full catalog: https://lightmysky.com/llms-full.txt > Every machine-readable file on this domain: https://lightmysky.com/.well-known/ai-catalog.json > Ask for Markdown with `Accept: text/markdown`, a `.md` address, or `?mode=agent`. # 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. Subject: Computing · Area: Software Engineering · Ages 18 to 20 Page: https://lightmysky.com/learn/computing/code-review-reading-a-change-you-did-not-write-mt_Hhe1Ou709s ## Ready when they can - 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 ## Lesson: Reading someone else's diff 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. **Example.** 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. *(drawing: Looking only at changed lines can miss a caller that still expects the old behavior.)* 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. **Example.** 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. **Recap.** 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.* ## Practice 8 questions on this page, each with its working shown. ## Needs first - [Branching, merging and resolving a conflict](https://lightmysky.com/learn/computing/branching-merging-and-resolving-a-conflict-mt_l3vFbU7L3E) - [Requirements: turning a wish into a testable statement](https://lightmysky.com/learn/computing/requirements-turning-a-wish-into-a-testable-statement-mt_TFb-YNpvT1) ## Optional connections - [Debugging as a Method: Reproduce, Isolate, Fix](https://lightmysky.com/learn/computing/debugging-as-a-method-reproduce-isolate-fix-mt_2JGE4ICRf6)