# What You Need in a Code Review Checklist (& What You Don't) | LinearB Blog
> Discover what your team needs in their code review checklist, what they don’t, and how you can automate code review checklists by repo.
_This is a markdown rendering of a live HTML page on linearb.io, generated for AI/LLM consumption — it is not a markdown-only site. To get the full HTML page instead, request this URL with an explicit `Accept: text/html` header (no wildcard, no markdown preference)._
[Blog](https://linearb.io/blog)
/
What You Need in a Code Review Checklist (& What You Don't)
# What You Need in a Code Review Checklist (& What You Don't)
By [Carlos Schults](https://linearb.io/blog/code-review-checklist#carlos-schults)
|
May 7, 2024
Code reviews are invaluable for the health of a codebase. During reviews, you can detect bugs, find opportunities to improve security and performance, and much more. But if you’re not using the best code review checklist, you could be harming your engineering efficiency unintentionally.
Our recent study from LinearB Labs revealed [developers wait on average 4 days for a pull request review.](https://linearb.io/blog/pull-request-pickup-time) That’s a lot of idle time. Even worse, we found that the majority of those reviews resulted in an “LGTM” type comment.
Let’s take a look at what your team needs in their code review checklist, what they don’t, and how you can automate code review checklists by repo to improve developer experience and engineering efficiency and ship features faster.
## **What to Add to Your Code Review Checklist**
Let’s start with some of the items that are indispensable in a code review checklist.
### **1\. Identify Obvious Bugs**
This is the primary function of a code review: Check if the code is working.
Even great engineers write code that has defects. Often, those defects are quite silly: an off-by-one error, a misspelled variable, parameters passed in the wrong order to a method, and so on.
Code reviews offer a great opportunity to catch these defects because, while the author often misses them, a different person with a fresh pair of eyes will spot them more easily.
### **2\. Look for Possible Security Issues**
When reviewing code, try to look for possible security issues that could be exploited. Your CI pipeline should make use of plugins and other tools that automatically check for many types of vulnerabilities. But when reviewing code, you might find problems the author was too sleep-deprived to notice—e.g. controller actions without protection against CSRF or SQL queries that concatenate user input and become vulnerable to injections.
[Ensure you’re tapping the right resources to look for security issues in your code by finding the best reviewer for the job automatically.](https://docs.gitstream.cm/automations/standard/review-assignment/review-sensitive-files/)
[](https://giphy.com/gifs/Bounce-TV-movie-7zMxwVRIkl8vQhnH1V)
_Even great developers can have a lapse in attention and make mistakes._
### **3\. Look for “Clever” Code**
Code readability is another vital area you should look into when reviewing code. First, remember that readability is, to a certain extent, subjective. Take a look at the following piece of code:
{ showList && }
This is a common idiom in JavaScript/React, and it allows rendering a component conditionally. However, a C# or Java developer might find that unreadable, and prefer something like this:
if (showList) { let return = ; }
In this example, I prefer the first snippet, even though I’m mostly a backend engineer myself. But this is just my opinion. The point is that code readability is a subjective judgment call that must take into account different coding styles and what’s idiomatic for each language.
**PRO TIP:** When evaluating readability keep an eye out for code that tries too hard to be clever.
What you should do when evaluating readability is to keep an eye out for code that tries too hard to be clever. That includes code that puts brevity above clarity, using somewhat obscure language constructs in order to save a few keystrokes.
### **4\. Check for Code Duplication**
When reviewing code, you’ll often spot some low-hanging fruit regarding [code duplication](https://linearb.io/blog/code-duplication/#:~:text=Simply%20put%2C%20it's%20when%20a,paste%20was%20the%20quickest%20solution.). For example, maybe the author planned to extract the duplication to a dedicated method but then forgot to do it. Sometimes there’s a nice abstraction just lurking around and the author can find it with the right push. Maybe the functionality already exists elsewhere and can be reused.
### **5\. Check Whether Names Are Descriptive Enough**
Naming is one of the hardest things in software engineering, but that doesn’t mean we should give up. When performing a review, look for opportunities to improve the names of variables, constants, class fields and properties, methods, classes, and so on.
**PRO TIP:** Look for opportunities to improve the names of variables, constants, class fields and properties, methods, classes, and so on.
Sometimes, the code is trying to be clever with the naming by picking fancier names than what’s needed. A good example is creating interfaces to abstract access to the system clock so they can unit test code that makes use of time. Fair enough, but then they name this abstraction “iTimeProvider,” or something like that, when in the real world there’s already an object that provides the time: a clock!
With the help of a patient, creative, and empathetic reviewer, engineers can find names that are creative yet simple and [adhere to the language used by the rest of the business.](https://linearb.io/blog/being-vp-of-software-development-is-harder-than-being-ceo#tips-to-translate-business-to-your-team)
### **6\. Look for Possible Performance Improvements**
Again, you should have [automatic checks and production monitoring](https://docs.gitstream.cm/) to detect performance issues. However, that doesn’t mean you shouldn’t look for opportunities to increase performance while doing code reviews. I’m thinking about easy finds like:
* an expensive operation inside a loop
* excessive allocations of objects
* inefficient string concatenations
* inefficient logging
You’ll often spot seemingly simple problems during the review that will go a long way in improving the code and its performance.
### **7\. Check the Presence and Quality of Tests**
Automated tests—including but not limited to unit tests—are code and, as such, you should also review them. When reviewing unit tests, check for:
* [**The presence of tests:**](https://docs.gitstream.cm/automations/label-prs-without-tests/) Did the author create tests for their change?
* **The quality of tests:** Do the tests created seem to effectively exercise the system under test? Do they follow agreed-upon best practices?
* **Readability:** Remember tests are also documentation. They should be simple and easy to understand.
* **Naming:** Are the tests named according to the team’s convention? Is it easy to understand what they’re about?
### **8\. Explain Your Changes**
When you feel that the author of a delta you are reviewing wrote less-than-perfect code because of a lack of knowledge, it’s important to take the time to educate them. One of the major benefits of code reviews is that they spread knowledge throughout the team and [help less-experienced developers level up their skills](https://linearb.io/blog/how-to-do-code-reviews-better/#constructive-feedback). Although each team member will have [their areas of expertise](https://docs.gitstream.cm/automations/standard/explain-code-experts/), the team will perform better if everyone has a comprehensive understanding of the codebase.
It can be hard to take the time to explain something, but think of it as a long-term investment that will improve the quality of the code to be reviewed, which will make reviews easier to conduct in the future. Better than catching bugs early is making sure that the bugs don’t appear at all!
Increasing knowledge among the team will also improve the overall quality of the codebase, resulting in reduced development costs. In this way, investing in learning is like preemptively paying down technical debt.
### **9\. Optional: Code Documentation**
I added this as optional because I think it really depends on the conventions and rules of each team. I personally am a big fan of [Docblocs](https://en.wikipedia.org/wiki/Docblock). That is code documentation such as XML comments in C#, Javadoc for Java, and phpDoc for PHP. By keeping comments in the code itself, this makes updating the documentation much easier and therefore more likely to happen.
During the build process, these comments can be used to generate documentation that is then uploaded to a server where they can be accessed by developers on the team. Such a style of documentation is particularly useful for teams creating software that’s used by third parties, such as libraries. Your mileage may vary, and that’s why I consider this optional.
## **What to Remove from Your Code Review Checklist**
As a bonus, let’s quickly go through some things that, in my opinion, should _not_ be a part of your code review process.
### **1\. Cosmetic Concerns**
You shouldn’t be wasting your time fixing lots of cosmetic/aesthetic issues during your code review. These should be taken care of by an automated tool like a linter or static analyzer. You can configure linters to enforce one of the established coding style guides ([AirBnB’s](https://airbnb.io/javascript/react/) is a popular one) or to enforce your company’s style.
What do I mean by cosmetics? Things like:
* whether to use tabs or spaces
* the position of opening brackets in code blocks
* whether to leave a space after **if**, **for**, and other keywords
* whether to leave a blank line in certain situations
* snake\_case vs camelCase vs PascalCase
### **2\. Testing**
In my view, reviewers shouldn’t test changes when performing a code review. When I say test changes, I mean pulling the branch to their machines, executing the application, and manually going to the changes in order to see if everything’s working properly.
If the reviewer feels the need to test a pull request in this way, this means that either the pull request is too large and complex, or the team lacks a proper testing strategy. Or probably both.
### **3\. Anything That Can Be Automated**
As a general rule, avoid doing anything in a code review that can be automated. For instance, I just talked about how you should review unit tests when performing reviews. Sure, but that review should _not_ include verifying whether the tests cover all possible branches of the code. That would be too time-consuming anyway, but there’s an automated way to check that: it’s called [branch coverage.](https://linearb.io/blog/what-is-branch-coverage/)
Another example would be [compliance or adherence to the tech stack agreed upon](https://docs.gitstream.cm/automations/change-deprecated-components/). There are ways to automate that, and it should be automated.
Another piece of the code review process that should be automated are notifications. Engineers shouldn’t be taking valuable time to ping another about a PR they created 4 days ago. Instead, [set Team Goals with LinearB](https://linearb.io/resources/engineering-leader-guide-to-goals-and-reporting) and use our developer workflow bot, WorkerB, to help dev teams course correct when a review has been waiting longer than your agreed-upon timeframe.
[](https://linearb.io/get-started/)
Promote your pull requests to merge 10x faster. [Get started with our free-forever account today!](https://linearb.io/get-started/)
## **Automate Your Code Review Checklist by Repo**
What’s even better than automating aspects of your code review checklist to cut down review time? Automating the whole review. Waiting 4 days for a LGTM review isn’t helping your code quality anyways, so why not?
We’ve set out to tackle this problem and help devs get their code merged faster. It boils down to this: every pull request is different. Some PRs are critical areas of your codebase that need more than one reviewer or a review from a subject matter expert. Some are just docs or image changes that could be merged automatically.
With [gitStream](https://github.com/linear-b/gitstream), you can create a clear set of rules and policies that automates how code gets reviewed and merged in each repo.
* Why do you need a human review on small changes like text corrections, images or css that passed all tests? Apply an auto-approve check to pull requests and speed up your time to merge.
* Want to assign reviews based on workload, review time, or area of expertise? gitStream review automations make sure the right person is assigned so your PR gets picked up faster and merged with higher confidence.
* Still recovering from a major failure and requiring 2 reviewers on every PR? Now you can relax with confidence. Create a review automation that assigns a specific person or requires 2 reviewers to any code changes in the most critical areas of your codebase.
## Improve developer productivity with LinearB
Find us on
[](https://www.linkedin.com/company/linearb)
[](https://devinterrupted.substack.com/)
## Your next read
[](https://linearb.io/blog/slack-jaime-delanghe-mcp-agent-context-channels)
Workflow
[Slack turns channels into the context engine for agentic AI](https://linearb.io/blog/slack-jaime-delanghe-mcp-agent-context-channels)
Slack Chief Product Officer Jaime DeLanghe breaks down how channels serve as the foundational context layer for human-agent collaboration. Learn why Slack is...
[](https://linearb.io/blog/code-generation-faster-shipping-isnt)
Workflow
[Code generation is faster than ever, but shipping value isn't](https://linearb.io/blog/code-generation-faster-shipping-isnt)
Your team writes more code than ever, but less reaches production. AI moved the bottleneck to code review. Here's how to measure it and unblock your pipeline.&n...
[](https://linearb.io/blog/ai-as-value-multiplier-human-centric-leadership)
Workflow
[AI as a value multiplier: a human-centric approach to engineering leadership](https://linearb.io/blog/ai-as-value-multiplier-human-centric-leadership)
Super.com's Matt Culver explains why AI should be used as a value multiplier, not a cost-cutter, advocating for a human-centric approach to engineering...
## Structured data
_Machine-readable metadata (JSON-LD) embedded in the page for search/AI context — not content rendered on the page itself._
```json
{
"@context": "https://schema.org",
"@type": "Organization",
"name": "LinearB",
"url": "https://linearb.io",
"logo": "https://assets.linearb.io/image/upload/v1715628027/logo-mark-lg.svg",
"description": "LinearB is the engineering productivity platform that helps engineering leaders prove AI is improving throughput without sacrificing delivery confidence, flow efficiency, or developer experience.",
"sameAs": [
"https://www.linkedin.com/company/linearb"
],
"award": [
{
"@type": "Award",
"name": "LinearB is a Leader in the 2026 Gartner® Magic Quadrant™ for Developer Productivity Insight Platforms",
"dateAwarded": "2026",
"awardedBy": {
"@type": "Organization",
"name": "Gartner®"
}
},
{
"@type": "Award",
"name": "Great Place to Work Certification",
"dateAwarded": "2025-2027",
"awardedBy": {
"@type": "Organization",
"name": "Great Place to Work"
}
},
{
"@type": "Award",
"name": "America's Best Startup Employers 2025",
"dateAwarded": "2025",
"awardedBy": {
"@type": "Organization",
"name": "Forbes Magazine"
}
}
],
"hasCertification": [
{
"@type": "Certification",
"name": "SOC 1 Type 2"
},
{
"@type": "Certification",
"name": "SOC 2 Type 2"
},
{
"@type": "Certification",
"name": "GDPR Compliance certification"
},
{
"@type": "Certification",
"name": "ISO 27001"
}
]
}
```
```json
{
"@context": "https://schema.org",
"@type": "Article",
"headline": "What You Need in a Code Review Checklist (& What You Don't)",
"url": "https://linearb.io/blog/code-review-checklist",
"author": {
"@type": "Person",
"name": "Carlos Schults"
},
"datePublished": "2022-03-31T12:24:28.000Z",
"dateModified": "2024-05-07T07:00:00.000Z",
"image": "https://assets.linearb.io/image/upload/v1720000000/code_review_checklist_f44efe8ece.png",
"publisher": {
"@type": "Organization",
"name": "LinearB",
"logo": "https://assets.linearb.io/image/upload/v1777485755/linearb-logo-2026.png"
},
"description": "Discover what your team needs in their code review checklist, what they don’t, and how you can automate code review checklists by repo.\n"
}
```
## More on linearb.io
### Top navigation
- [Book a Demo](https://linearb.io/book-a-demo)
- [AI Code Reviews — Catch security risks, bugs, and spec mismatches](https://linearb.io/platform/ai-code-reviews)
- [AI & Productivity Insights — See how AI tools affect cycle time and delivery speed](https://linearb.io/platform/ai-developer-productivity-insights)
- [Measure AI Impact — Track AI adoption and tie it to delivery outcomes](https://linearb.io/use-case/measure-ai-impact)
- [MCP Server — Chat with your data to spot patterns and boost output](https://linearb.io/platform/mcp-server)
- [Resource Allocation — Cost initiatives and shape your investment strategy](https://linearb.io/platform/resource-allocation)
- [Cost Capitalization — Capitalize engineering costs with audit-ready reports](https://linearb.io/platform/cost-capitalization)
- [Dev Team Management — Set targets and tie throughput to business outcomes](https://linearb.io/platform/goals-and-reporting)
- [DevOps Workflow Automation — Policy-based PR routing, approvals, and tests](https://linearb.io/platform/ai-workflow-governance)
- [AI Powered Support — Unify AI and human code delivery in one clear view](https://linearb.io/use-case/ai-powered-support)
- [Optimization — Surface friction with feedback and MCP insights](https://linearb.io/platform/developer-experience)
- [Reporting — Spot what's working and what needs attention](https://linearb.io/use-case/measuring-developer-experience)
- [Surveys — Turn developer feedback into actionable signals](https://linearb.io/platform/developer-surveys)
- [Platform overview](https://linearb.io/platform/overview)
- [Register now](https://linearb.io/event/engineering-productivity-gap)
- [Customers](https://linearb.io/customers)
- [Pricing](https://linearb.io/pricing)
- [Why choose LinearB — Explore your data. Measure performance. Act to improve it.](https://linearb.io/why-linearb)
- [APEX framework — The operating model for AI-era engineering teams](https://linearb.io/resources/apex-framework)
- [Anti-FAQ — The questions other vendors won't answer](https://linearb.io/why-linearb/anti-faq)
- [Security — Enterprise-grade compliance and zero code access](https://linearb.io/security)
- [Build vs. buy — The hidden cost of building it yourself](https://linearb.io/resources/build-vs-buy)
- [Dev Interrupted Podcast — Conversations with engineering leaders](https://linearb.io/dev-interrupted/podcasts)
- [Reports & Guides — Deep dives on productivity and delivery](https://linearb.io/resources)
- [Webinars — Expert sessions on productivity and AI](https://linearb.io/resources?category=workshops)
- [Metrics Benchmarks — See how your engineering org stacks up](https://linearb.io/resources/software-engineering-benchmarks-report)
- [Blog — Product updates and practical insights](https://linearb.io/blog)
- [Help Center — Documentation, setup, and support](https://linearb.helpdocs.io)
- [API Docs](https://docs.linearb.io/api-overview)
- [Status](https://www.linearbstatus.com/)
- [Integrations](https://linearb.io/integrations)
- [LinearB is a Leader in the 2026 Gartner® Magic Quadrant™ for Developer Productivity Insight Platforms](https://linearb.io/resources/gartner-magic-quadrant-dpi-platforms-2026)
- [Sign in](https://app.linearb.io/login)
- [Enterprise](https://linearb.io/solutions/enterprise)
- [Contact](https://linearb.io/contact-us)
- [About us](https://linearb.io/about-us)
- [Careers](https://linearb.io/careers)
- [Service agreement](https://linearb.io/services-agreement)
- [Privacy policy](https://linearb.io/privacy-policy)
- [DPA](https://linearb.io/data-processing-agreement)
- [Security FAQ](https://linearb.io/security-faq)
- [Substack](https://devinterrupted.substack.com/)
### Footer
_Additional links from the site footer, not repeated from the top navigation above._
- [GitHub](https://github.com/linear-b)
- [LinkedIn](https://www.linkedin.com/company/linearb)
- [Twitter](https://twitter.com/LinearB_Inc)