How to Do Code Reviews That Actually Improve Code

Most teams already do code reviews. Far fewer get real value from them. Pull requests sit for days, reviewers argue about bracket placement, and the bug that mattered slips through because everyone was skimming a 1,500-line diff.

A good review process does 3 things: it catches problems a single author misses, it spreads knowledge across the team, and it keeps work moving. This guide gives you a reviewer checklist, a way to write comments people don’t dread, and the team rules that make reviews fast.

What a code review is really for

Before you open a diff, be clear about the goal. Google’s public engineering practices guide calls its core rule the senior principle: reviewers should favor approving a change once it definitely improves the overall health of the codebase, even if it isn’t perfect. As the guide puts it, there is “only better code.”

That framing changes how you review:

• You are not the author. Your job is to make sure the change is sound, not to rewrite it the way you would have.
• Progress beats perfection. A change that is clearly better than what’s there today should merge, with optional polish noted.
• Code health is the bar. Don’t approve changes that make the system harder to understand or maintain, even small ones. Those costs pile up as technical debt.

Reviews also build shared ownership. When 2 people understand every change, you lose less when someone goes on vacation or leaves.

The reviewer checklist: what to look at, in order

Review from the top down. If the design is wrong, line-level comments are wasted effort. This order is adapted from Google’s what to look for in a code review.

A few notes on the areas that cause the most trouble.

Functionality and edge cases

Read the code as a user and as an attacker. What happens with empty input, a null value, a very long string, a duplicate request or 2 requests at the same time? For UI changes, ask for a screenshot or a short demo. It is much faster than pulling the branch.

Security

You don’t need to be a security specialist to catch common mistakes. Look for string-built SQL queries, user input rendered without escaping, missing authorization checks and API keys pasted into code. Our guides to secure coding practices and the OWASP Top 10 cover the patterns worth memorizing.

Tests

Ask whether the tests would actually fail if the logic broke. A test that only checks that a function “returns something” adds noise, not safety. Check that tests sit at the right level, which our guide to unit, integration and end-to-end testing explains.

Every line, honestly

If you don’t understand a section, say so. “I can’t follow this loop, can you explain or simplify it?” is a valid review comment. If code confuses a reviewer today, it will confuse the next person who maintains it.

Key takeaway: Review design and correctness first, then tests and readability. Let automated tools handle formatting so human attention goes where machines can’t help.

How to write comments people actually want to read

The tone of review comments shapes whether developers ask for reviews early or hide work until the last minute. A few habits help a lot.

Comment on the code, not the person. “This function does 3 things, can we split it?” lands better than “You made this too complicated.”

Explain why. “Let’s use a parameterized query here so user input can’t change the SQL” teaches something. “Use a parameterized query” only gives an order.

Label how important each comment is. The single biggest source of friction is an author who can’t tell a must-fix from a passing thought. Google’s guide suggests prefixing minor points with “Nit:”. The Conventional Comments format goes further with labels such as:

• issue (blocking): a problem that must be fixed before merge
• suggestion (non-blocking): an improvement the author can take or leave
• question: you need context before you can judge
• nitpick: a small preference
• praise: something done well

Offer a path forward. If you flag a problem, suggest a fix or point to an example in the codebase. Many platforms let you propose an exact code change the author can accept with one click.

Say what’s good. A short “Nice test coverage on the retry logic” costs nothing and makes the critical comments easier to hear.

Move long debates offline. If a thread goes back and forth more than twice, talk it through on a call, then write the outcome in the pull request so others can follow.

How to keep pull requests moving

Slow reviews hurt the whole team. Google’s guide sets a clear expectation: “One business day is the maximum time it should take to respond to a code review request.” Ideally, responses come much sooner, so a change can go through several rounds in a day.

That doesn’t mean dropping everything the moment a request arrives. Context switching is expensive. Review at natural breaks: after finishing a task, after lunch or after a meeting. If you can’t do a full review soon, reply with when you’ll get to it or suggest another reviewer.

Other habits that speed things up:

• Approve with comments. If the remaining comments are minor and you trust the author to handle them, approve now and note what’s left. This saves a full round trip, especially across time zones.
• Review the whole change at once. Dripping out comments over several sessions forces the author to keep switching back.
• Use draft pull requests for early feedback on direction, and mark them ready when the code is.
• Track review time. Long review queues show up as slower lead time for changes, one of the DORA metrics many teams watch.

Tips for authors: make your pull request easy to review

Fast, useful reviews start with the author. A reviewer can’t do good work on a giant, unexplained diff.

Keep changes small. Google’s guide on small changes says around 100 lines is usually a reasonable size, while 1,000 lines is usually too large. It also notes that file count matters: 200 lines in 1 file may be fine, but spread across 50 files it usually isn’t. Split refactors from behavior changes, and split large features into a series of focused pull requests. Short-lived branches, covered in our Git branching strategies guide, make this easier.

Write a real description. Cover what changed, why, how you tested it and anything you want the reviewer to look at closely. Link the ticket. Add screenshots for UI changes.

Review your own diff first. Read it on the review platform before asking anyone else. You’ll catch leftover debug logs, commented-out code and typos.

Let automation go first. Make sure CI is green before requesting review so humans aren’t checking things a machine could.

Respond to every comment. Fix it, push back with a reason, or agree to a follow-up ticket. Don’t leave threads hanging.

What to automate so humans can focus

People are expensive reviewers of formatting. Move every mechanical check into your CI/CD pipeline so it runs before anyone looks at the code.

AI review tools now leave first-pass comments on many teams’ pull requests. They can catch obvious bugs and save time, but they also generate noise and can miss context about why code exists. Treat them as another automated check, not a replacement for a human approver. Our look at AI coding assistants covers how teams are fitting these tools into their workflow.

On GitHub, a CODEOWNERS file automatically requests reviews from the people or teams who own each part of the codebase. Combined with a branch protection rule that requires code owner approval, it makes sure sensitive areas like payments or authentication always get the right eyes.

Where to start: a 6-step plan for your team

You don’t need a big process change. Start here:

1. Write down your review standard. One page: what reviewers check, what “approve” means and that approving a clear improvement is the goal.
2. Agree on a response time. One business day as the maximum is a sensible default for most teams.
3. Adopt comment labels. Pick a simple set such as blocking, non-blocking, question and nit, and use them consistently.
4. Automate formatting and linting. Turn on an auto-formatter and linter in CI so style debates disappear.
5. Set a soft size limit. Encourage pull requests that a reviewer can finish in one sitting, and flag very large ones for splitting.
6. Add a pull request template. Prompt authors for the what, why, testing notes and screenshots.

Review the process after a month. Ask the team what’s slowing reviews down and adjust.

Conclusion

Code reviews improve code when reviewers focus on design, correctness, security and tests, when comments explain the why and make their importance clear, and when pull requests are small enough to review properly. Automate the mechanical checks, respond within a day, and approve changes that make the codebase better. Do that consistently and reviews stop being a bottleneck and become one of the best ways your team learns.

Sources

• Google Engineering Practices: The Standard of Code Review — senior principle of approving changes that improve code health, “Nit:” prefix
• Google Engineering Practices: What to look for in a code review — design, functionality, complexity, tests, naming, comments and style checks
• Google Engineering Practices: Speed of Code Reviews — one business day maximum response, LGTM with comments, handling interruptions
• Google Engineering Practices: Small CLs — guidance on change size and file count
• Conventional Comments — comment labels and blocking or non-blocking decorations
• GitHub Docs: About code owners — CODEOWNERS file locations and required code owner reviews