A practical code review checklist for small teams

Small teams usually review code because a branch protection rule says they must, not because they agreed on what a review is for. The result is familiar: some reviews are a quick "LGTM", others turn into long arguments about formatting, and real problems such as a missing authorisation check slip through because nobody was looking for them.

A short, shared checklist fixes most of this. It tells reviewers where to spend their attention, tells authors what will be checked before they ask for review, and keeps style debates out of the conversation by sending them to a style guide or a linter.

The checklist below draws on two public sources that have held up well: Google's engineering practices documentation on code review, and the OWASP Secure Code Review Cheat Sheet. It is written for teams of two to twenty people who review pull requests on GitHub, GitLab or a similar host. Copy it into your contributing guide and adapt it.

Agree on what "approve" means

Google's guide states the principle that the rest of its advice depends on: reviewers "should favor approving a CL once it is in a state where it definitely improves the overall code health of the system being worked on, even if the CL isn't perfect". (CL, or changelist, is Google's word for a pull request.)

Two consequences follow. First, an approval is not a claim that the code is perfect; it is a claim that the change makes the codebase better and introduces no known problems. Second, reviewers should not block on polish. The same guide suggests prefixing optional comments with "Nit:" so the author knows they can ignore them. It also sets two useful rules for disagreements: technical facts and data overrule opinions, and on matters of style "the style guide is the absolute authority".

Write your team's version of that standard in one sentence at the top of your checklist. Everything else is easier once people agree on what they are approving.

Before requesting review: the author's checklist

The fastest review is one where the author has already done the obvious checks. Ask authors to confirm these before they request a reviewer:

• The change does one thing. Google's guidance on small changes says the right size is "one self-contained change" and offers a rough guide: about 100 lines is usually reasonable and 1,000 lines is usually too large, with the reviewer's judgement deciding. A 200-line change across 50 files may also be too large.
• Tests are in the same pull request as the code they cover, and they fail without the change.
• Automated checks pass: build, linter, formatter, type checks and any dependency or secret scanning your team runs.
• The description explains why, not only what: the problem, the approach, anything deliberately left out, and how to verify the change.
• Self-review is done. Read your own diff in the pull request view; you will catch debugging output, commented-out code and unrelated edits.
• Screenshots or a short recording are attached for user-facing changes, since reviewers cannot easily judge UI from code alone.

The reviewer's checklist

Google's "What to look for in a code review" page orders the topics by importance, starting with design. The checklist below follows that order and adds a security section based on OWASP.

Design first, details last

Review the overall design before reading line by line. If the approach is wrong, line comments are wasted effort for both people. When you do find a design problem, say so early and plainly, and suggest a direction rather than a full rewrite.

Think about behaviour, not just code

Google's guide notes that reviewers should think about edge cases and concurrency and, for user-facing changes, consider asking for a demo. Concurrency deserves special attention because, as the guide says, such problems "are very hard to detect by just running the code".

Check the tests as carefully as the code

"Tests do not test themselves," as the Google guide puts it. A test that always passes is worse than no test, because it creates false confidence. Ask whether each test would fail if the code it covers were broken, and whether it will produce false positives when unrelated code changes.

A security pass for every diff

The OWASP Secure Code Review Cheat Sheet distinguishes baseline reviews of a whole codebase from diff-based reviews of pull requests. For everyday pull requests, its diff-based steps translate into a short pass any reviewer can do:

1. Impact on existing controls. Does the change weaken or bypass authentication, authorisation, validation or logging that already exists?
2. New attack surface. New endpoints, file uploads, redirects, webhooks or third-party integrations need their own checks.
3. Trust boundaries. Where does data cross from untrusted (user, network, third party) to trusted? Is it validated there?
4. Common vulnerability patterns. String-built SQL or shell commands, unencoded output, unsafe deserialisation, path construction from user input and home-made cryptography.
5. Regression. Does the change remove a check that a previous fix added?

OWASP is clear that manual review complements automated tools rather than replacing them: SAST and dependency scanners find known patterns quickly, while humans are better at business logic and context. Run the tools in CI so reviewers can spend their time on what tools cannot see.

Writing review comments people can act on

Most review friction comes from tone and ambiguity, not from the technical point. These habits help:

• Label severity. Use a prefix such as "Nit:" for optional polish, and say clearly when something must change before merge.
• Explain the reason. "This query runs once per item in the loop; can we load them in one query?" is more useful than "inefficient".
• Comment on the code, not the person. "This function is hard to follow" rather than "you made this confusing".
• Offer an alternative when you reject an approach, or ask a question if you are not sure.
• Approve with comments when remaining points are minor and you trust the author to address them. Google's speed guidance describes this "LGTM with comments" approach and recommends it especially across time zones.

How fast should reviews be?

Slow reviews cost more than most teams realise. Google's guidance argues that most complaints about strict reviewers disappear when responses are fast, and sets a clear upper limit: "One business day is the maximum time it should take to respond to a code review request." It also says you should not interrupt focused work to review; respond at the next natural break instead.

The key measure is response time, not total time to merge. If you cannot do a full review soon, reply with when you will, suggest another reviewer, or leave initial broad comments. For teams spread across India, Europe and the Americas, aim to respond before the author's working day ends, or before it starts the next morning.

Route reviews automatically with CODEOWNERS

On GitHub, a CODEOWNERS file assigns owners to paths, and those owners are automatically requested for review when a pull request changes files they own. Draft pull requests do not trigger requests until they are marked ready. If required reviews are enabled, a repository admin can also require approval from a code owner before merging.

Place the file in .github/, the repository root or docs/; GitHub searches those locations in that order and uses the first one it finds. It must be on the pull request's base branch, and files over 3 MB are not loaded. The last matching pattern takes precedence. A small example:

# .github/CODEOWNERS
# Default owners for everything in the repository
*                    @your-org/maintainers

# Later matches win: billing code needs the payments team
/src/billing/        @your-org/payments

# Infrastructure and CI changes need the platform team
/infra/              @your-org/platform
/.github/workflows/  @your-org/platform

Teams named in CODEOWNERS must have explicit write access to the repository. Note that some .gitignore syntax does not work here: negation with ! and character ranges with [ ] are not supported.

The checklist in one place

Paste this into your pull request template or contributing guide:

## Author
- [ ] One self-contained change; split if it does several things
- [ ] Tests added or updated, and they fail without this change
- [ ] Build, lint, type checks and scanners pass
- [ ] Description explains why, how to verify, and what is out of scope
- [ ] Self-reviewed the diff; screenshots attached for UI changes

## Reviewer
- [ ] Design: fits the system, right place, right time
- [ ] Functionality: edge cases, failures, concurrency
- [ ] Complexity: understandable quickly, no speculative generality
- [ ] Tests: correct, meaningful, maintainable
- [ ] Security: validation, authorisation, injection, secrets, new attack surface
- [ ] Naming, comments and docs
- [ ] Optional points marked "Nit:"; blocking points stated clearly

Next steps

Start small: agree on the one-sentence approval standard, add the checklist to your pull request template, and set a response-time expectation. After a month, look at which checklist items caught real problems and which never did, and trim the list. A checklist that people actually use is worth more than a comprehensive one that everyone skips.