Spot the mistake
Read this line fast: "The the bus is late."
Did you see the double "the"? Most writers do not. Their eyes read what they meant to write.
Code is the same. The person who wrote it often cannot see the mistake. A second person finds it in seconds.
Key words
| Word | What it means |
|---|---|
| Code review | Another person reads your code to find mistakes and ways to improve it. |
| Paired programming | Two people write code together at one computer. |
| Driver | In paired programming, the person who types. |
| Navigator | In paired programming, the person who watches, thinks ahead and spots mistakes. |
| Walkthrough | An informal talk where the author explains the code to others. |
| Inspection | A formal, planned review with set roles and a written record. |
| Defect | A mistake in the code. |
The cells students fill in are left blank in this preview.
Three ways to review
There are three common kinds of review.
Paired programming: two people, one computer, all the time.
Informal walkthrough: the author shows the code to colleagues (people they work with) and talks through it. No papers, no rules.
Formal inspection: a planned meeting with roles, a checklist and a written list of defects.
Quick check: which review?
Have a go
Quick check: which review?
3 questionsYour answers are marked here and are not kept. A college account keeps every student’s marks.
Compare the three
| Paired programming | Informal walkthrough | Formal inspection | |
|---|---|---|---|
| People | Two | The author and a few colleagues | A team with set roles |
| When | While the code is written | After a part is written | After a part is written, on a planned day |
| Paperwork | None | None or a few notes | A checklist and a written record |
| Cost in time | Two people at once | Low | High |
| Best for | Hard problems and teaching | Quick feedback | Code that must be very safe, such as payments |
The cells students fill in are left blank in this preview.
Driver and navigator
In paired programming, the driver types. The navigator watches and thinks about the next step.
The navigator asks: what if the list is empty? Is the name clear?
Swap roles often, for example every 10 minutes. Both people stay busy and both learn.
Try it: review this code
def total_cost(prices):
total = 0
for price in prices:
total = price # reviewer: is this right?
return total
print(total_cost([2, 3, 5]))
# The answer should be 10. Run it. Find the mistake. Fix it.
A code review checklist
| Question | Why it matters |
|---|---|
| Does it do what was asked? | Working code that does the wrong thing is still wrong |
| Are names clear? | Other people must read it later |
| What if the input is empty, zero or very large? | These odd inputs are called edge cases. They cause many defects |
| Is any code repeated? | Repeated code means repeated mistakes |
| Are there tests? | Tests prove it keeps working |
| Are the comments kind? | Review the code, never the person |
The cells students fill in are left blank in this preview.
Say it kindly
data-callouts.tip.label
Write "What happens if the list is empty?" and not "You forgot the empty list." Ask questions. Say what you like too. A review is for the code, not against the person.