Skip to content

Code review: what is checked?

A review is not a matter of taste and not a ritual. It is a second look at a change before it goes live — and it has a clear checklist.

  • Who it is forClients, project managers
  • LevelCollaboration
  • Reading timeabout 6 minutes
  • Last updated16 October 2026

What you will learn

  • What a review actually checks — in order of importance
  • Why every finding needs a failure scenario
  • What a review cannot do
  • How you can tell that one has taken place

The checklist, in this order

  • Does the change do what it should? Compared against the task, not against one’s own taste.
  • What happens in the error case? Missing data, duplicate entries, unreachable systems.
  • Are permissions and responsibilities checked — on the server, not only in the interface?
  • Are there tests for the cases that hurt, and do they fail without the change?
  • Does the change fit the structure of the application, or does it create a second way of doing the same thing?
  • Is it readable enough that the next change to it does not become archaeology?

The order is not arbitrary. A review that starts at point six and never reaches points one to three has spent the expensive time on the cheap questions.

Every finding needs a failure scenario

This is the rule that keeps a review useful: whoever raises an objection names a concrete input and the concrete wrong behaviour that follows from it — or a named rule that is being violated.

“I would do this differently” is not a finding. “With a quantity of 0, this line divides by zero, and the interface then shows an empty page instead of a message” is one. The difference decides whether a review finds bugs or generates discussions.

It also follows that a review without findings is the expected normal outcome, not a sign of carelessness. Anyone who has to find something in every review will eventually find matters of taste.

A real-world example

A finding that prevented a release

A change was meant to add a filter to a list. In the review it became apparent that the filter bypassed the permission check: anyone who opened the address with a particular parameter saw records from other departments. This was not reachable through the interface, but it was through the address bar.

The finding was described in two sentences, with the exact address and the result. The fix took twenty minutes. Without the second look it would have come after the first incident — under different circumstances.

What a review cannot do

  • It does not replace tests. Reading finds different errors than running.
  • It does not replace testing in the browser. That a function looks right does not mean the page reaches it.
  • It finds no errors in code that nobody reads — a change of a thousand lines is not really reviewed.

That is why our rule is: one change per topic, reviewable in one pass. Anyone who packs three topics into one change gets a review of the first.

Common misconceptions

It is a second view of the same task. Whoever wrote a change no longer reads it without bias — that is not a question of character.

It shifts time forward. An error that is caught in review costs minutes; the same error in production costs the fix plus the consequences.

Small changes in particular are underestimated. The permission check in the example above was one line.

Further reading

What does clean code mean?What is checked under readability in a review.
Why software tests need concrete failure casesThe other part of safeguarding.
From idea to tasksWhat a review measures the change against.

About the author

Fabian Lücker is managing partner of PHP-Schmiede KG in Rheine and has worked in software development since 2007. He is responsible for development and design, and writes here about decisions that come up in real projects.

Questions about this article? Write to us