# Code Reviews: My Checklist for Every Pull Request
By Govind Bajaj · 2025

Tags: code-review, methodology, best-practices, software-engineering, workflow
I have reviewed 800+ pull requests. The same 8 checks catch 90% of issues. Here's the checklist I use on every PR — as a reviewer and as an author.
I have reviewed over eight hundred pull requests in the past three years.

The same eight checks catch ninety percent of issues. Security vulnerabilities, performance regressions, maintainability problems — they all show up in these eight areas.

This is the checklist I use on every PR, whether I am the reviewer or the author. As an author, I run through it before requesting review. As a reviewer, I check each item systematically.

## Check 1: Does It Solve the Right Problem?

The most expensive mistake in software development is building the wrong thing correctly. Read the issue or ticket first. Does this PR actually solve that problem? Or does it solve a related problem that is not what was asked?

I caught a PR last month that implemented a complex caching layer for product queries. The issue was about adding a missing database index. The caching layer was impressive engineering, but the index would have solved it with a one-line migration.

## Check 2: Are There Tests?

Not do the tests pass — are there tests at all?

I look for tests that verify the new behavior, tests for edge cases (empty input, null values, boundary conditions), and tests that would catch regressions if this code is modified later.

If there are no tests, I ask why. Sometimes the answer is reasonable (pure UI changes). Usually it is not.

## Check 3: Error Handling

Happy path code is easy to write. Error handling separates production code from prototypes.

Checklist: Are all async operations wrapped in try/catch? Are errors logged with enough context to debug? Does the user see a helpful message instead of a stack trace? Are database transactions rolled back on failure?

## Check 4: Security

Quick security checks that catch most issues: No secrets in code (API keys, passwords). Input validation on all external data. Authentication checks on protected routes. Output encoding to prevent XSS. SQL injection protection (parameterized queries or ORM).

## Check 5: Performance

N+1 queries are the most common performance issue I see. Any loop that calls the database is suspicious.

Other checks: Are images optimized? Is there unnecessary re-rendering in React? Are large lists virtualized? Are API responses paginated?

## Check 6: Readability

Code is read more often than it is written. Checklist: Variable names explain their purpose. Functions do one thing. Complex logic has comments explaining why, not what. No commented-out code. Consistent formatting.

## Check 7: Type Safety

Any is a red flag. Type assertions (as) are suspicious. Silent null handling (obj?.field) without explicit handling can hide bugs.

## Check 8: Does It Follow Existing Patterns?

Consistency beats novelty. If the codebase uses service functions for database access, do not add raw queries in a route handler. If error handling uses a custom AppError class, do not add console.log errors.

## The Review Format

I structure my reviews in three sections:

Required changes: Must be addressed before merge. Security issues, broken functionality, missing tests.

Suggestions: Nice to have. Naming improvements, refactoring ideas, alternative approaches. Marked as optional.

Questions: Things I do not understand. The author clarifies, and sometimes the question reveals a bug neither of us had noticed.

## Takeaways

- Eight checks catch 90% of issues: problem, tests, errors, security, performance, readability, types, consistency
- Always read the issue first — building the wrong thing correctly is expensive
- Error handling separates production code from prototypes
- Any and as in TypeScript are red flags that hide bugs
- Structure reviews as required changes, suggestions, and questions
- Run this checklist as an author before requesting review — it speeds up the process
- The goal is better code, not perfect code — know when to stop debating