What is code review? Process, best practices and checklist

Why teams review code

Testing shows that code does what its tests expect. Review asks whether it does what the team actually needs, in a way the team can maintain. The two catch different problems, which is why mature teams use both.

• Find defects early. A logic error caught in review costs minutes; the same error in production costs an incident, a fix and a customer conversation.
• Keep the codebase consistent. Review is where conventions — naming, error handling, data access — are applied to every change.
• Share knowledge. Every review teaches at least one more person how part of the system works, reducing single points of knowledge.
• Security and compliance. Standards such as SOC 2 and PCI DSS expect evidence that changes were reviewed before release.

Types of code review

Teams use several forms of review, often together:

The code review process, step by step

Whatever the Git host, an effective pull request review follows the same steps:

• 1. Prepare a small pull request. One logical change, with a description that says why it exists, how it was tested and what reviewers should focus on.
• 2. Let automation go first. Build, tests, linters, static analysis and an AI reviewer comment before any person looks, so humans don't spend time on what tools catch.
• 3. Review for the expensive problems. Correctness, security and impact on other code first; style last.
• 4. Comment clearly. Mark which comments block the merge and which are suggestions, and explain why.
• 5. Respond and iterate. The author fixes or explains. Disagreements that go past two rounds are faster to settle in a short call.
• 6. Approve and merge. Once required approvals and checks pass. Approve when the change improves the code, even if it isn't how you would have written it.

What reviewers should look for

Work from the most expensive problems down. Formatting belongs to linters; a reviewer's time is best spent where tools are weakest.

• Correctness. Does the change do what the ticket asks? Are edge cases, empty inputs, errors and concurrent access handled?
• Security. Is every request authorised for the resource it touches? Is user input validated? Are secrets kept out of the code?
• Impact beyond the diff. Which callers, jobs or services depend on the changed code, and do they still work?
• Performance. Queries inside loops, unbounded result sets, missing indexes and expensive work on hot paths.
• Tests. Do the tests cover the behaviour that changed, including failure paths?
• Readability and design. Will the next person understand this in six months? Does it fit the existing architecture?

Code review best practices for authors

• Keep pull requests small. A widely cited study of review at Cisco (SmartBear, 2006) found defect detection falls sharply beyond roughly 200–400 lines per review and after 60–90 minutes of reviewing.
• Write a real description. Why the change exists, how you tested it, screenshots for UI, and anything risky.
• Review your own diff first. Catch leftover debug code and accidental changes before anyone else spends time on them.
• Separate refactors from behaviour changes. Mechanical changes in one pull request, behaviour in another, so reviewers can skim the first and focus on the second.
• Respond to every comment. Fix it, or explain why not; don't leave threads silently unresolved.

Code review best practices for reviewers

• Respond quickly. Waiting for a first review is usually the longest part of a pull request's life. Many teams aim for a first response within one working day.
• Improve the code, don't demand perfection. Google's engineering guidance: approve a change once it definitely improves the overall health of the codebase, even if it isn't perfect.
• Label your comments. Make clear what blocks the merge and what is optional — for example with Conventional Comments labels such as 'issue (blocking):', 'suggestion:' and 'nitpick:'.
• Explain why. A comment that explains the risk teaches; a comment that only says 'change this' gets argued with.
• Praise good work. Pointing out a well-handled edge case is cheap and makes the rest of the review easier to hear.

How to speed up code review

Slow reviews are usually a queueing problem, not a reading problem. The changes that help most:

• Smaller pull requests. They wait less, are reviewed more thoroughly, and merge with fewer rounds.
• An automated first pass. AI review gives feedback within minutes, so authors fix routine issues before a person looks.
• A first-response target. An agreed target, such as same working day, keeps pull requests from sitting idle.
• Spread the load. Code owners plus a rotation avoid one senior engineer becoming the bottleneck.
• Measure the wait. Track time to first review and pull request cycle time to see where time actually goes.

Manual review, static analysis and AI code review

These are layers, not alternatives. Linters and static analysis apply fixed rules quickly and deterministically. AI code review reads the change in context and can reason about intent — for example, noticing that an endpoint loads a record by id without checking the caller owns it. Human reviewers judge design, trade-offs and whether the change is the right thing to build.

AI code review best practices

• Let AI go first, humans decide. Use AI review as the first pass on every pull request; people stay responsible for approval.
• Tune the noise. Set severity filters and comment limits so developers read the findings instead of skimming past them.
• Teach it your conventions. Encode team rules and context so findings match how your team builds software.
• Review AI-written code too. Code from coding assistants needs the same review — often more, because it looks plausible even when it calls APIs that don't exist.
• Measure what gets acted on. Track which findings developers fix, and adjust rules accordingly.

Code review metrics

Track a few signals rather than many. Time to first review and pull request cycle time show whether review is a bottleneck. Review depth — comments per changed line, or the share of pull requests merged with no comments — shows whether reviews are real. Escaped defects traced back to reviewed changes show whether review catches what matters.

Code review checklist

• The pull request description explains why, not just what.
• The change does what the linked ticket asks, including edge cases.
• Every endpoint or job checks that the caller may access the data it touches.
• User input is validated before it reaches queries, shells, file paths or templates.
• No secrets, tokens or credentials are committed.
• Errors are handled or propagated with context, not swallowed.
• No queries inside loops; result sets are bounded or paginated.
• Callers of changed functions and APIs still work.
• Tests cover the changed behaviour, including failure paths.
• Names and structure follow team conventions.