Code Review: Reading a Change You Did Not Write · seed 1 · A4, ink-friendly. The answer key prints on its own page for grown-ups.

Reading someone else's diff

Computing · Software Engineering · ages 18-20
Name ______________________   Date ____________

  1. Which comment is about correctness?

    • This crashes on empty input
    • I would rename this variable
    • This line needs a blank line above it

  2. What does a review ask about a diff?

    • Who wrote it and when
    • How many lines it adds
    • Whether it works, breaks nearby code, and reads clearly

  3. A naming preference must be fixed just like a crash.

    Circle one:   True   False

  4. A change passes its own tests yet breaks code elsewhere. What must the reviewer check?

    • The callers outside the diff
    • The spelling inside the diff
    • The age of the diff

  5. Which remark follows the questioning habit?

    • Rename this at once.
    • What happens when the input is empty?
    • This is wrong.

  6. Which comment still matters if the author disagrees about style?

    • Use my favourite names.
    • This breaks the caller that passes zero.
    • Add more comments everywhere.

  7. A twenty-line change renames two variables, fixes an empty-input crash, and alters a function every caller depends on. Which pair of comments still matters if the author disagrees about style?

    • The crash fix and the caller impact
    • The two renames
    • One rename and a plea for shorter names

  8. A reviewer demands a rename and ignores an empty-input crash. What went wrong?

    • They checked the callers too soon
    • They asked too many questions
    • They put taste above behaviour
LightMySky · lightmysky.comW1-mt_Hhe1Ou709s-s1

Answer key

For grown-ups. Fold this page away before handing over the rest.

Reading someone else's diff W1-mt_Hhe1Ou709s-s1

  1. This crashes on empty input · A crash on real input is behaviour, not taste.
  2. Whether it works, breaks nearby code, and reads clearly · Intent, nearby breakage, and clarity are the three review questions.
  3. False · Taste is optional; broken behaviour is not.
  4. The callers outside the diff · Breakage hides with the users of the changed code.
  5. What happens when the input is empty? · A question checks understanding before ordering work.
  6. This breaks the caller that passes zero. · A broken caller hurts whatever the naming taste is.
  7. The crash fix and the caller impact · Crash and caller impact survive any style debate.
  8. They put taste above behaviour · The crash is the must-fix; the rename is optional.
Worksheet · LightMySky