Code Review

The question is not whether the code is good. It is what will this cost the next person to change it — and whether that cost is worth naming now.

Working code that is hard to change is the expensive case, and it is invisible to tests. That is what review is for. Style has a formatter; correctness has a test suite; neither has an opinion about the thing that will make the next feature take three days instead of one.

Read for the story first

Before any judgement, read it the way someone will read it in six months with no context: top to bottom, following the names.

Where does it stop making sense? Where does a name promise one thing and the body do another? Where is a paragraph of explanation needed to bridge two lines?

Those points are the review. They are where the code and its meaning have separated, and they matter more than anything a checklist finds. A reader tripping is not a reader's failing.

What is actually worth saying

In order of what it costs later:

The claim that is false. A type that permits states the domain does not have. A name that says one thing while the code does another. An invariant enforced at one call site and assumed at four. These are wrong now and get more wrong.