Conducting a code review that improves the code

Goal

Approve changes that make the codebase healthier than before, catch design and correctness problems early, and do so quickly enough that reviews do not block integration.

Prerequisites

A small, self-contained change with a description that states intent, and tests that exercise the new behaviour.

Steps

1. Read the description first and decide whether the change makes sense at all; if the goal is wrong, say so before reading code.
2. Look at the most important parts: the design, then correctness and edge cases, then tests. Google's guide lists design, functionality, complexity, tests, naming, comments, style, consistency and documentation.
3. Comment on the rest in decreasing order of importance; mark optional suggestions as such ("nit:").
4. Prefer questions and reasons over commands: "This branch is unreachable when x is empty, is that intended?"
5. Approve when the change improves overall code health, even if it is not perfect; request changes only for real problems, not personal preference.
6. Respond within one business day; if a full review takes longer, send partial feedback.

Expected result

Reviews find design and correctness issues rather than only formatting; authors receive actionable comments; changes wait hours, not days.

Limits and test basis

The procedure comes from the cited guide and general practice; it does not replace automated checks for style and static errors, which should run before human review. Very large changes cannot be reviewed well by any procedure and should be split.