# code-review-checklist is a list of questions for a reviewer, not a linter > The code-review-checklist repository contains a MIT licensed document of review questions grouped into implementation, logic errors, error handling, dependencies, security and privacy, performance, usability and accessibility, ethics, testing and readability. There is no code and nothing to install, and most of the items are phrased as questions rather than as assertions, which makes the list a prompt for thought rather than a gate. **mgreiler/code-review-checklist** — This code review checklist helps you be a more effective and efficient code reviewer. - Repository: https://github.com/mgreiler/code-review-checklist - Website: http://www.awesomecodereviews.com - Stars: 1,093 · Forks: 196 - Language: Unknown - License: MIT - Published: 2026-10-19 · Updated: 2026-10-19 · Language: en - Canonical page: https://hysenlabs.com/projects/mgreiler-code-review-checklist ## Two files, and that is the entire repository The repository contains LICENSE and README.md. There is no code, no configuration, no test suite and no build. The description says the code review checklist helps you be a more effective and efficient code reviewer, and the homepage is awesomecodereviews.com. So this is a document, and the decision to adopt it is a decision about a process artefact rather than about a dependency. There is no version to pin, because the repository has no GitHub releases, and there is no upgrade path to plan. The last push was on 2026-07-29, and the repository is not archived. That framing matters for how you read the rest. A checklist that ships as a script, a linter configuration or a CI action enforces itself. A checklist that ships as Markdown asks a person to remember it, and the value therefore depends almost entirely on how the team chooses to use it. The licence is MIT, so copying the file into an internal wiki, adapting the wording to your own stack or turning parts of it into your own review template carries no obligation beyond keeping the notice. The topic list on the repository is worth reading as a description of intent: checklist, clean code, code quality, code review, code reviews, merge request, pull requests and readability, which is a taxonomy of the review conversation rather than a feature set. For more insights into code reviews, the README points at awesomecodereviews.com, so the repository is the entry point to a larger body of material rather than the whole of it. ## The implementation section is really a design review The first group of questions is called Implementation, and it is the one that reaches beyond the diff. It asks whether the code change accomplishes what it is supposed to do, whether the solution can be simplified, and whether the change adds unwanted compile time or run time dependencies. Then it asks about the framework, API, library or service being used, in two directions. Is something being used that should not be used, and could an additional framework, API, library or service improve the solution. Those two questions together are a dependency and design judgement, which is the point where a reviewer is most likely to be wrong and most valuable. The abstraction questions follow. Is the code at the right abstraction level, is the code modular enough, and can a better solution be found in terms of maintainability, readability, performance or security. Then the reuse question, which is the one that catches duplicated helpers: does similar functionality already exist in the codebase, and if yes, why is it not reused. The section closes with best practices, design patterns and language specific patterns, and with a question about Object-Oriented Analysis and Design Principles, naming the Single Responsibility Principle, the Open-Close Principle, the Liskov Substitution Principle, Interface Segregation and Dependency Injection. Two observations. The SOLID reference is spelled out in full rather than abbreviated, which is right for a document that will be read by people at different levels. And the section is written for a reviewer who is expected to argue about design, not just to spot defects, which is a different review from the one most teams default to. ## Logic errors and error handling get their own prompts The second group is short, and its shortness is the design. Under Logic Errors and Bugs there are two items, and both are questions rather than instructions: can you think of any use case in which the code does not behave as intended, and can you think of any inputs or external events that could break the code. That is a different technique from looking for the bug you can see. The question is asking the reviewer to generate a scenario, which is a reviewer's job rather than a test author's job, and the two questions together cover the two sources of failure, a use case that the author did not anticipate and an input or event that arrives from outside. The error handling and logging group is more operational. Is error handling done the correct way, should any logging or debugging information be added or removed, and are error messages user-friendly. Then the question that decides whether a log is worth anything: are there enough log events and are they written in a way that allows for easy debugging. That is a test of the log rather than of the code, and it is the item most likely to be skipped in a hurry, which is why having it written down helps. There is a useful tension here that the checklist does not resolve. Asking whether enough log events exist is unanswerable without knowing what the operator will need at three in the morning, and the checklist has no way to supply that context. It is a prompt for a conversation with the person who will debug the system, not a rule that can be applied. ## Dependencies and security assume a modern supply chain The Dependencies group is the most specific to a contemporary stack, and it is where the checklist is most likely to be directly reusable. It asks whether new or updated dependencies are necessary, whether package names, publishers, sources and versions are correct and supported, and whether lockfiles were updated with known vulnerabilities and licence constraints checked. The last of those is a compound question and a good one, because it puts the vulnerability check and the licence check in the same breath, which is how they actually collide. A dependency that is secure and permissively licensed but abandoned is a different problem from one that is maintained and copyleft. Then two questions about reach. Were updates to documentation, configuration or README files made as required by this change, and are there potential impacts on other parts of the system, on public APIs, on data formats or on backward compatibility. The second one is the question that stops a change from being merged while it looks like an isolated improvement. The security and data privacy group covers the ground you would expect. Does the code introduce security vulnerabilities, is authorization and authentication handled correctly, is user input validated, sanitized and escaped to prevent attacks such as cross site scripting or SQL injection, is sensitive data such as user data or credit card information securely handled and stored, and is the right encryption used. It also asks whether the change reveals any secret information such as keys, passwords or usernames, and whether data retrieved from external APIs or libraries is checked for security issues. The two questions that are usually missing from a review checklist are both here. The one about secrets, and the one about the code you pull in from someone else's library rather than the code you wrote. ## Ethics and morality are asked about explicitly Most review checklists in this space stop at security and performance. This one has a section titled Ethics and Morality, and it is the section that makes the document more than a defect list. It asks whether the change makes use of user data in a way that might raise privacy concerns, and whether the change exploits behavioral patterns or human weaknesses. It asks whether the code, or what it enables, might lead to mental and physical harm for some users. It asks whether the code adds or alters ways in which people interact with each other, and if so, whether appropriate measures are in place to prevent, limit or report harassment or abuse. It asks whether the change leads to the exclusion of a certain group of people or users, and whether it introduces unjust impact on people, particularly those related to sensitive characteristics such as race, ethnicity, gender, nationality, income, sexual orientation, ability, and political or religious belief. And it asks whether the change introduces any algorithm, AI or machine learning bias. The list of characteristics is long enough that it is worth saying plainly what the section is for. These are the questions that a reviewer is least equipped to answer alone, because judging whether a change exploits behavioral patterns or causes unjust impact requires people who understand the domain the code operates in. The value of writing the question down is that the reviewer at least knows to ask it and knows to escalate it, rather than assuming someone else did. That is also why the final section, Experts' Opinion, asks whether a specific expert, such as a security expert or a usability expert, should look over the code before it can be accepted, and whether the change impacts different teams and should be reviewed by them as well. The two sections are deliberately adjacent in the document's logic. ## Testing and readability are asked as questions too The Testing and Testability group has four items. Is the code testable, have automated tests been added or related ones updated to cover the change, do the existing tests reasonably cover the code change across unit, integration and system tests, and are there test cases, inputs or edge cases that should be tested in addition. The Readability group is the longest in the document, and it is the one that reads most like a set of prompts for a conversation. Is the code easy to understand, which parts were confusing to you and why, can the readability be improved by smaller methods, and by different function, method or variable names. Then the structural questions: is the code located in the right file, folder or package, do certain methods need restructuring to have a more intuitive control flow, and is the data flow understandable. Then the comments. Are there redundant or outdated comments, could some comments convey the message better, would more comments make the code more understandable, and could some comments be removed by making the code itself more readable. And finally, is there any commented-out code. The question that stands out is which parts were confusing to you and why. That is a question about the reviewer's own experience, and it is the item in the whole document that turns a review from a checklist walk into a source of information for the author, because the answer identifies something the author did not realise a reader would trip over. ## How to actually use a list this long The document contains roughly sixty questions across eleven sections, and the description promises to make reviewers more effective and more efficient. Those two goals are in tension with each other, and any team adopting this list has to resolve that tension rather than assume it away. The obvious approach is to treat the sections as a menu rather than a script. The Implementation questions and the dependencies and security questions are the ones that can block a merge. The performance questions are the ones that make sense on a change that touches a hot path. The ethics questions belong in a different setting entirely, a design review rather than a diff review, because they are questions about the product and not about the code. The readability questions are the ones a reviewer should be asking anyway. A workable pattern is to run the full list on the changes where it is cheap, a new service or a first design in a module, and to run a shorter agreed subset on the routine diffs, with the checklist living in the pull request template so that a reviewer who is tired of it is not asked to run it in their head from memory. The other thing to decide is what happens when the answer is no. A checklist whose every item can fail a review becomes a rubber stamp within a month, and one whose items are advisory becomes documentation nobody reads. Naming a handful of items as blocking is what keeps the rest meaningful. The document is MIT licensed, so a team can rewrite it, drop the sections that do not apply and add the questions their own stack raises, and the site at awesomecodereviews.com is where the wider material lives. ## Conclusion code-review-checklist suits a team that has no shared review vocabulary and wants a starting point, or a reviewer who wants a prompt for the questions they forget to ask about design, dependencies, accessibility and ethics. It does not suit a team that wants automated enforcement, since the repository contains only a README and a licence file, and a large change in a mature codebase is not going to be reviewed against sixty prompts. Verify first which sections apply to your own stack, since the dependency, lockfile and licence questions assume a package manager and a supply chain process, and decide in advance which handful of items are worth blocking a merge on. ## FAQ ### What is the code-review-checklist repository? It is a MIT licensed document of code review questions, grouped into implementation, logic errors and bugs, error handling and logging, dependencies, security and data privacy, performance, usability and accessibility, ethics and morality, testing and testability, readability and experts' opinion. The repository contains only a README and a licence file. ### Does the code-review-checklist include any tooling or automation? No. There is no code, no configuration and nothing to install, so the checklist depends entirely on a team choosing to use it in its review process. ### What does the security section of the checklist cover? Whether the change introduces vulnerabilities, whether authorization and authentication are handled correctly, whether user input is validated, sanitized and escaped against attacks such as cross site scripting or SQL injection, whether sensitive data is securely handled and stored, whether the right encryption is used, and whether secrets such as keys, passwords or usernames are revealed. ### Why does the code-review-checklist include a section on ethics? It asks whether the change uses user data in a way that raises privacy concerns, exploits behavioral patterns or human weaknesses, might lead to mental or physical harm, alters how people interact with each other without measures against harassment, excludes a group of users, introduces unjust impact on people with sensitive characteristics, or introduces algorithmic or machine learning bias. ### How often is the code-review-checklist updated? The repository is not archived and the last push was on 2026-07-29. There are no GitHub releases, so the document is tracked through the repository history rather than through versions. ## Sources - [Issues](https://github.com/mgreiler/code-review-checklist/issues) - [License: MIT](https://github.com/mgreiler/code-review-checklist/blob/master/LICENSE) - [mgreiler/code-review-checklist on GitHub](https://github.com/mgreiler/code-review-checklist) - [Project website](http://www.awesomecodereviews.com) - [README](https://github.com/mgreiler/code-review-checklist/blob/master/README.md) --- Hysen Labs editorial analysis, written from the project's own repository and release notes. Cite the canonical page: https://hysenlabs.com/projects/mgreiler-code-review-checklist