Code Review Checklist: 35 Items for Reviewing Pull Requests

A code review checklist helps the team review pull requests with clear criteria. It reduces subjective comments, avoids rework, and makes it easier to separate what should block a PR from what can become an improvement for later.

In practice, a good checklist does not need to be huge. It needs to remind the reviewer to look at the points that most often slip through: change context, readability, tests, security, compatibility, and deployment risk.

Quick code review checklist

• Is the goal of the PR clear?
• Does the change solve only the proposed problem?
• Is the code simple to read and consistent with the project standards?
• Are there tests covering the main path and failure cases?
• Were inputs, permissions, and sensitive data handled?
• Does the change avoid breaking APIs, contracts, or existing behavior?
• Were logs, metrics, and rollback considered when needed?

That is the summary. If you only have a few minutes to review a small PR, start here. For larger changes, use the full checklist below.

When to use a code review checklist

A code review checklist makes the biggest difference when the team starts to grow. With three or four people, many things are still implicit. Code standards, architecture decisions, and the way people review end up being passed along day to day.

When the team starts having more squads, more projects, and more new people joining, that model starts to fail. Some reviews become too fast. Others go into style details that lint should already handle. And bigger discussions, such as architecture or solution scope, end up appearing too late inside the PR.

The checklist helps because it makes review less dependent on each person’s preference. It creates a simple agreement about what needs to be evaluated before approving a change.

How to use this checklist

The most common mistake is treating every item as mandatory in every PR. That makes the process heavy and creates comments that do not change the result very much.

Use the checklist as a guide for attention. In a small text adjustment, tests, architecture, and rollback may not even make sense. In authentication, security and compatibility become priorities. In a database migration, rollback and production impact need to be considered before merge.

A good rule: anything that can break the product, expose data, create rework, or make maintenance harder deserves attention. The rest can become a suggestion, follow-up, or automatic adjustment through lint and tools.

Complete code review checklist

1. change context

• Does the PR explain which problem is being solved?
• Is the change connected to the ticket, issue, or context agreed on by the team?
• Is the scope small enough to be reviewed carefully?
• Were files changed outside the scope justified?
• Is there any important tradeoff described in the PR description?

A PR without context forces the reviewer to interpret the intent of the change alone. This usually creates worse comments, because the review is limited to the diff and loses the reason behind the decision.

2. readability and maintainability

• Is the code easy to understand without a verbal explanation from the author?
• Do function, variable, and class names make the intent clear?
• Could the logic be smaller without becoming harder to understand?
• Is there duplication that creates a real maintenance risk?
• Does the code follow the standards already used in the project?
• Do comments explain decisions or difficult parts, without narrating the obvious?

Readability is not about personal taste. The best signal is simple: could someone on the team come back to this code three months from now and understand what needs to change without calling the author?

3. behavior and business rules

• Does the change cover the behavior expected by the product?
• Were error cases handled predictably?
• Were empty, invalid, or unexpected inputs considered?
• Do old business rules continue to work?
• Is there any edge case that should be described in the PR?

Many bugs that pass review do not show up in the syntax. They show up in behaviors that seemed obvious to the person who wrote the code, but were not clear to the person reviewing it.

4. tests

• Are there tests for the main path of the change?
• Are there tests for failures, permissions, or invalid inputs?
• Do the tests validate behavior instead of fragile implementation details?
• Did any existing test need to be changed? If so, does the reason make sense?
• Do the tests run reliably in CI?

Not every PR needs a new set of tests. But changes in business rules, authorization, payments, data, or public APIs almost always need some coverage. If the author decided not to test, that decision should be clear.

5. security

• Were user inputs validated in the right place?
• Were permissions and authorization checked on the backend?
• Are sensitive data kept out of logs, API responses, and error messages?
• Were secrets, tokens, and credentials kept out of the code?
• Were new dependencies evaluated for risk and necessity?
• Does the change avoid common issues like SQL injection, XSS, and improper access?

Security in review does not need to become a full audit. The reviewer needs to evaluate the most likely risks for that type of change. Authentication, authorization, sensitive data, and new dependencies deserve a closer look.

6. performance

• Does the change add queries, loops, or external calls in sensitive areas?
• Is there a risk of N+1, heavy queries, or unnecessary processing?
• Does the code handle real data volume well?
• Were long-running operations moved to the right place?
• Were cache, pagination, or asynchronous processing considered when they make sense?

The review does not need to predict every future bottleneck. Even so, it is important to check whether that code remains reasonable when it leaves the local example and starts dealing with production data.

7. compatibility and contracts

• Does the change break any public API or contract used by other services?
• Do older clients continue to work?
• Are migrations compatible with gradual deployment?
• Are flags, versions, or fallback needed?
• Was API, event, or payload documentation updated when needed?

This point is easy to forget when the PR looks small. A change to a field, status, enum, or payload can break another service without looking dangerous in the diff.

8. logs, metrics, and observability

• Are there enough logs to investigate failures in production?
• Do logs have useful context, such as IDs and flow step?
• Were sensitive data kept out of logs?
• Do metrics or alerts need to be updated?
• Are important errors captured in a way that is visible to the team?

Not every PR needs to touch observability. But if the change creates a new flow or changes something critical, someone needs to be able to understand what happened when things go wrong.

9. deploy and rollback

• Does the PR depend on an environment variable, migration, or external configuration?
• Can the deployment happen without interrupting users?
• Is there a clear way to roll back if something fails?
• Does the change need a feature flag?
• Did CI pass with the relevant tests, lint, and checks?

Review also means looking at the path to production. A change can be correct in the code and still be risky if the deployment requires manual steps that no one documented.

What should block a PR

Not every comment needs to prevent merge. To keep review healthy, the team needs to agree on what should actually block a PR.

In general, the PR should be blocked when there is:

• clear functional bug
• security failure
• risk of data loss or leakage
• public contract break without a migration plan
• missing test in a critical flow
• change that does not solve the described problem
• deployment without rollback in a sensitive area

These points justify asking for changes before merge. When there is real risk, the reviewer needs to be clear about what must be adjusted.

What can become a suggestion

Some comments are useful, but they do not need to block the merge.

• name preference when the current name is already clear
• formatting covered by lint
• refactor outside the scope of the change
• pattern change with no practical impact in that PR
• small documentation improvement
• architectural discussion that needs a broader conversation

In these cases, make it clear that the comment is a suggestion. Something like “this could be clearer if…” usually works better than treating every adjustment as mandatory.

Checklist for the person who opened the PR

The author should also use the checklist before requesting review. This saves everyone time.

• Did I explain the goal of the PR?
• Did I review my own diff before requesting review?
• Did I remove debug code, temporary logs, and unrelated changes?
• Did I run tests, lint, and local checks when it makes sense?
• Did I leave comments in the PR where the reviewer needs context?
• Did I explain decisions that may look strange from the diff alone?
• Did I mention whether there is deployment, migration, or compatibility risk?

A good self-review avoids the kind of comment that the author would find in two minutes by calmly looking at the diff.

Checklist for the person reviewing

• Did I understand the problem before reviewing the solution?
• Did I look at behavior, not just code style?
• Did I separate blockers from suggestions?
• Did I explain the reason behind the most important comments?
• Did I avoid asking for large refactors that are outside the PR scope?
• Did I make it clear when something needs to change before merge?

A good review is not measured by the number of comments. It helps the author improve the PR without turning every adjustment into a long discussion.

Checklist template for a GitHub pull request

You can place this template in .github/pull_request_template.md and adapt it to the way your team works.

## What changed?

Describe in a few lines what this PR changes and why.

## Context

Link to the ticket, issue, or related discussion:

## Type of change

- [ ] Bugfix
- [ ] Feature
- [ ] Refactor
- [ ] API change
- [ ] Migration or database change
- [ ] Security
- [ ] Performance
- [ ] Documentation

## Author checklist

- [ ] I reviewed my own diff before requesting review
- [ ] I removed debug code, temporary logs, and out-of-scope changes
- [ ] I explained decisions that may not be clear from the diff alone
- [ ] I ran the relevant tests, lint, and checks
- [ ] I updated documentation, examples, or contracts when needed
- [ ] I mentioned deployment, migration, or compatibility risks

## Tests

Describe how the change was tested.

- [ ] Automated tests
- [ ] Manual test
- [ ] Not applicable

## Points for the reviewer to look at more carefully

List files, decisions, or parts of the flow that need a closer look.

## Risks and rollback

Is there any known risk? How can we roll back if something goes wrong?

## Review checklist

- [ ] The goal of the PR is clear
- [ ] The scope is aligned with the problem
- [ ] The code is readable and consistent with the project
- [ ] Error cases and edge cases were considered
- [ ] Tests cover the relevant scenarios
- [ ] Security, permissions, and sensitive data were handled
- [ ] APIs, events, and contracts remain compatible
- [ ] Deployment and rollback were considered when needed

How to adapt this checklist to your team

Copying a ready-made checklist is a good start, but the best checklist is the one that reflects the team’s real problems.

Look at the last bugs that reached production. See which ones passed through review. Then ask: which item would have helped someone notice this earlier?

This exercise is usually more useful than building a huge list with every possible engineering principle. If the team keeps struggling with migrations, put migrations in the checklist. If the problem appears in authorization, give security more space. If PRs get too large, put scope and context limits near the top.

The checklist should also change over time. When an item stops creating value, it can be removed. When a problem appears more than once, it can become part of the list. The document needs to follow the code and the way the team works.

What to automate in code review

Reviewers should not spend time on everything. Formatting, lint, tests, known vulnerabilities, and repeated patterns can be checked by tools.

This frees the team to look at what requires context: product decisions, user impact, solution design, deployment risk, and code clarity.

At Kodus, for example, the idea behind Kody is exactly to help teams automate part of this repetitive work inside the pull request flow. Team rules, code standards, and recurring problems can be reviewed more consistently, while engineers focus on the decisions that need judgment.

If your team already has clear standards, those standards can become rules. If it does not yet, the checklist can be the first step toward finding which rules actually make sense.

Examples of good code review comments

A checklist works better when the feedback is also clear. Vague comments put the author on the defensive. Specific comments show what the problem is and what can be done.

🫠 Bad example:

This code is confusing. 

😎 Better example:

The discount rule ended up split between the controller and the service. I think it will be easier to maintain if this decision stays only in the service, because that is where the other discounts are already handled.

🙄 Bad example:

Missing test.

😉 Better example:

Can you add a test for the case where the user has no permission? This flow touches authorization and is easy to break without noticing.

😪 Bad example:

Improve name.

👍 Better example:

I would change data to invoiceDueDate. With the current name, I had to go back a few lines to understand which date was being used.

The pattern is simple: state the problem, explain the risk, and suggest a path when you have one.

Frequently asked questions about code review checklists

What is a code review checklist?

It is a list of points authors and reviewers use to evaluate a pull request before merge. It helps the team review context, code quality, tests, security, compatibility, and deployment risks.

How many items should a code review checklist have?

Enough to cover the team’s most common risks. For daily use, something between 10 and 20 items usually works better than a huge list. For larger PRs, it is worth having extra sections by type of change.

Should every checklist item block the PR?

No. Some items are blockers, such as a security failure, clear bug, or contract break. Others are suggestions, such as small improvements in naming, documentation, or internal organization.

What should you review in a pull request?

Start with the goal of the change. Then look at behavior, readability, tests, security, compatibility, and deployment risk. Style and formatting should be automated whenever possible.

What is the difference between manual and automated code review?

Automated review checks patterns that a tool can detect, such as lint, tests, secrets, vulnerabilities, and recurring rules. Manual review looks at context, intent, product impact, and decisions that depend on judgment.

How do I adapt a code review checklist for my team?

Use real bugs, recent incidents, and repeated comments in PRs as the base. If a problem appears several times, it probably deserves to become a checklist item or an automated rule.

To wrap up

A good code review checklist does not turn review into bureaucracy. It creates simple alignment around what the team needs to evaluate before merge.

Start small. Put the checklist in the pull request template. Review a few PRs using the main items. Then adjust based on what actually shows up in the team’s work.

The best sign that the checklist is working is when comments become clearer, PRs arrive more prepared, and the team discusses personal preference less in every review.