A Code Review Checklist – Focus on these 10 Important Topics

A code review checklist, together with clear review guidelines, helps a team inspect changes systematically and keep its attention on high-impact risks.

The research is promising, but more nuanced than “checklists always win.” In a controlled experiment with 70 developers, a checklist was associated with better review effectiveness and efficiency on one complex task, while a guided checklist performed better on a smaller task. The researchers caution that the participants’ generally low review performance limits the strength of the results. Treat a checklist as a focusing aid, not a guarantee that a review is complete.

You can find the checklist I use in my code review workshops also in a compact format on GitHub. Let’s start with a quick overview of the code review checklist topics.

Code Review Checklist Overview

1. Implementation
2. Logic Errors and Bugs
3. Error Handling and Logging
4. Usability and Accessibility
5. Ethics and Morality
6. Testing and Testability
7. Dependencies
8. Security and Data Privacy
9. Performance
10. Readability

Code Review Checklist for Code Authors

Code review checklists are not only something for the code reviewers. Instead, as the author of the code change, follow the code review best practice and be your own reviewer!

So, before sending out the code for review, make sure that:

• The code builds and passes the required static-analysis checks
• The code passes the relevant unit, integration, and system tests
• You have double-checked for spelling mistakes
• You cleaned up temporary comments, debugging code, and outdated TODOs
• You described what changed, why it changed, and how you verified it
• You understand and can explain every part of the change, including any AI-generated code

Apart from that, you, as the code author, should run through the same code review checklist as the reviewer.

Code Review Checklist for Code Reviewers

As a code reviewer, it is your task to look for the most important issues first. It is easy to get hung up on nitpicking, but that is rarely the most valuable use of review time.

In one of our large studies at Microsoft, we investigated what valuable code review feedback looks like. We saw that comments revealing larger structural or logical problems are perceived as much more valuable than comments that focus on minor issues.

This is where code review checklists come into play. A great checklist directs your attention to the important and most valuable issues. Below you will find the checklist that I also use during my code review workshops. It is divided into ten sections, each with questions that guide your attention. First, let’s look at what AI-assisted development changes.

What Changes When Code or Reviews Are AI-Assisted?

The ten review topics do not fundamentally change when a coding agent or large language model (LLM) writes the code. The quality bar and the author’s responsibility remain the same. What changes are some of the failure modes:

• Verify generated API calls, package names, versions, and behavior against authoritative documentation or the package registry. A 2025 USENIX study of package hallucinations in 576,000 generated code samples found nonexistent package references in output from commercial and open-source models.
• Make sure generated tests assert the required behavior rather than merely repeat the implementation’s assumptions. A useful test should fail when the production change is absent or broken.
• Check AI-generated pull request summaries against the actual diff, requirements, and design decisions.
• Treat AI review comments and proposed fixes as hypotheses to verify, not as approval. The 2026 SWR-Bench study of 1,000 real-world pull requests found substantial room for improvement in current automated review systems. Aggregating independent review passes improved F1 scores by up to 43.67%, but it did not make human judgment optional.
• Follow your organization’s data-handling rules before sending source code, prompts, logs, secrets, or personal data to an external AI service.

An AI reviewer can be useful for self-review or a focused additional pass. It should supplement the checklist, automated checks, and accountable human review. For practical tool and workflow guidance, see the overview of AI code review tools.

Implementation

• Does this code change do what it is supposed to do?
• Can the solution be simplified?
• Does this change add unwanted compile-time or run-time dependencies?
• Is a framework, API, library, or service used that should not be used?
• Could an additional framework, API, library, or service improve the solution?
• Is the code at the right abstraction level?
• Is the code modular enough?
• Can a better solution be found in terms of maintainability, readability, performance, or security?
• Does similar functionality already exist in the codebase? If yes, why isn’t it reused?
• Are there any best practices, design patterns, or language-specific patterns that could substantially improve this code?
• Where relevant, does the code follow the project’s established design principles and language idioms?

Logic Errors and Bugs

• Can you think of any use case in which the code does not behave as intended?
• Could boundary values, missing or invalid input, concurrency, retries, timeouts, or partial failures break the code?

Error Handling and Logging

• Is error handling done the correct way?
• Should any logging or debugging information be added or removed?
• Are error messages user-friendly?
• Are there enough log events, and are they written in a way that allows for easy debugging?
• Do logs and error messages avoid exposing secrets or unnecessary personal data?

Usability and Accessibility

• Is the proposed solution well-designed from a usability perspective?
• Is the API well documented?
• Is the proposed solution (UI) accessible?
• Is the API/UI intuitive to use?

Ethics and Morality

• Does this change make use of user data in a way that might raise privacy concerns?
• Does the change exploit behavioral patterns or human weaknesses?
• Might the code, or what it enables, lead to mental or physical harm for some users?
• If the code changes how people interact, are appropriate measures in place to prevent, limit, and report harassment or abuse?
• Could the change unfairly exclude or disadvantage any group of users?
• If the change uses an algorithm, AI, or machine learning, were its outcomes evaluated for harmful bias across relevant user groups, for example gender/racial/political/religious/ableist bias?

Testing and Testability

• Is the code testable?
• Have automated tests been added, or have related ones been updated to cover the change in functionality?
• Do the existing tests reasonably cover the code change (unit/integration/system tests)?
• Are there some test cases, input, or edge cases that should be tested in addition?
• Do new or changed tests fail when the implementation is absent or intentionally broken?
• For probabilistic or LLM-powered behavior, do evaluations cover representative and adversarial cases, including failure and fallback paths?

Dependencies

• Are new or updated dependencies necessary?
• Are package names, publishers, sources, and versions correct and supported?
• Were lockfiles updated, and were known vulnerabilities and license constraints checked?
• Were updates to documentation, configuration, or README files made as required by this change?
• Are there any potential impacts on other parts of the system, public APIs, data formats, or backward compatibility?

Security and Data Privacy

• Does the code introduce any security vulnerabilities?
• Are authorization and authentication handled correctly?
• Is untrusted input validated and handled with context-appropriate defenses, such as parameterized queries and output encoding to prevent security attacks such as cross-site scripting or SQL injection?
• Is sensitive data minimized and securely collected, transmitted, logged, stored, and deleted?
• Does this code change reveal secrets such as API keys, tokens, passwords, or other credentials?
• Are responses from external services, files, webhooks, and model outputs treated as untrusted input?
• If the product uses an LLM, could prompt injection expose data or trigger tools and actions without the correct authorization?

For more guidance during reviewing code for security vulnerabilities, check out this secure code review checklist.

Performance

• Do you think this code change decreases system performance?
• Do you see any significant opportunity to reduce latency, memory, compute, network, or model usage and cost?

Readability

• Is the code easy to understand?
• Which parts were confusing to you and why?
• Can the readability of the code be improved by smaller methods?
• Can the readability of the code be improved by different function, method, or variable names?
• Is the code located in the right file/folder/package?
• Do you think certain methods should be restructured to have a more intuitive control flow?
• Is the data flow understandable?
• Are there redundant or outdated comments?
• Could some comments convey the message better?
• Would more comments make the code more understandable?
• Could some comments be removed by making the code itself more readable?
• Is there any commented-out code?

Expert Opinions

In addition to the 10 topics on this code review checklist, think about whether someone else should have a look at this code.

Ask yourself:

• Do you think a specific expert, like a security expert or a usability expert, should look over the code before it can be accepted?
• Will this code change impact different teams, and should they review the change as well?

Well, that’s it. You looked and thought about the most pressing issues with this code review checklist. Congratulations!

Now, one of the exercises that I do in my code review workshops is to reflect with the participants on this checklist for code reviews by answering three questions:

1. Which parts of the code review checklist are you focusing on the most?
2. Which parts of the code review checklist do you tend to neglect?
3. Do you believe some of those points are more important for a checklist for code inspection? Why?

But what about coding styles and conventions?

Maybe during this exercise, you realized that I did not check whether the code follows the right coding style. So, is that not important?

Short answer: it is important. A clear coding style guide helps teams keep a codebase consistent. Consistency can make reviews faster, help people move between projects, and keep the code readable and maintainable. For example, Google has one of the fasted code review turnaround times specifically because of those clear and consistent rules.

Google, for example, publishes ready-made style guides for many languages. They are a useful starting point, but adapt a guide to the needs of your codebase and team.

Document the ground rules and automate the objective ones. Revisit them when the team’s needs change, but do not relitigate established style preferences in every review. This article explains how to get a team to agree on a coding standard.

Automate what can be automated

But, once you decide how your codebase should look, take the time to install and configure tooling properly so that code formatting becomes a matter of pressing a button.

Also, there is much more you can do. Use static analysis tools, such as Datadog Static Code Analysis or CodeQL to free up the time of your human code reviewers. Depending on their rules and configuration, these tools can enforce style, flag defect patterns, and detect classes of security vulnerabilities. It is worth the initial effort. Similarly, AI code review tools can help you with a first pass of the code review, but they are not a replacement for human judgment.

Be respectful, humble, and kind

Finally, the quality of the code review feedback does not only depend on WHAT you are saying but also on HOW you are saying it. So, the best code review feedback is worth nothing when it isn’t carefully phrased, humble, and kind.

For starters, phrase non-blocking feedback as suggestions instead of demands. For example, instead of writing “Variable name should be removeObject,” say, “What about calling the variable removeObject?” For more input, read my article on how to give respectful code review feedback.

Print out this code review checklist

As you need this code review checklist always next to you, I prepared a beautiful printable version for you. You can download the code review checklist as a printable PDF for free here. Alternatively, check it out on GitHub, and don’t forget to star it. Another resource that might be super valuable for you is my code review e-book.