The Code Review Checklist I Use With My Team

TL;DR: A good code review checks five things: the change does what the ticket asks, it is readable and consistent with the codebase, it avoids framework pitfalls, it is secure, and it is accessible. Automate formatting and linting so humans focus on logic, keep pull requests to roughly 200 to 400 lines, review within one working day, and label every comment so the author knows how much it matters.

This is the checklist my team at ProLance IT uses for React and Next.js projects. It has two parts: what the author does before asking for a review, and what the reviewer checks. Copy it, then adapt it to your stack.

Key takeaways

• Automate everything a machine can check: formatting, linting, type checking, tests.
• The author reviews their own diff first. Most problems disappear here.
• Small pull requests get better reviews and get merged faster.
• Review for correctness and maintainability, not personal style.
• Label comments as blocking or non-blocking.

What should the author check before requesting a review?

The author is the first reviewer. Before requesting a review, my team checks:

• The pull request does one thing, and the title says what that is.
• The description explains why the change exists, links the ticket, and lists anything the reviewer should look at closely.
• UI changes include screenshots or a short recording, including mobile.
• The author has read the whole diff once, as if someone else wrote it.
• No leftover debug logs, commented-out code or unrelated changes.
• Lint, type check and tests pass locally and in CI.
• The change is roughly 200 to 400 lines. If it is bigger, split it.

That size limit is not arbitrary. SmartBear’s study of code review at Cisco found that reviewers find defects much less reliably once a review grows past about 400 lines, and large pull requests also sit in the queue longer.

What should reviewers check first?

Start with the big picture, then zoom in. Reading line by line before understanding the change leads to many small comments and missed big problems.

Correctness

• Does the change do what the ticket asks, including the edge cases?
• What happens with empty data, slow networks, errors and duplicate submissions?
• Are loading, empty and error states handled in the UI?
• Will this break existing behaviour anywhere else?

Design and readability

• Is the code in the right place, following the project structure? (Ours is described in How to Structure a Large Next.js App.)
• Could a new team member understand it without asking the author?
• Are names clear and specific?
• Is there duplicated logic that already exists somewhere in the codebase?

What React and Next.js issues should reviewers look for?

These are the issues I catch most often in React and Next.js code:

• Effects that should not exist. Derived values computed in a useEffect and stored in state instead of being calculated during render.
• Missing or wrong effect dependencies, which lead to stale data or infinite loops.
• Unstable list keys, such as array indexes in lists that can be reordered or filtered.
• Client components where server components would do. Adding "use client" to a whole page to make one button interactive sends far more JavaScript to the browser than needed.
• Data fetching in the wrong place, for example fetching in a client effect when the page could fetch on the server.
• Premature memoization. useMemo and useCallback everywhere make code harder to read and often save nothing.
• Secrets or server-only code imported into client components.

What security checks belong in every review?

Security is not a separate phase. Every reviewer checks the basics:

• Authorization happens on the server, next to the data. Hiding a button in the UI is not access control.
• Every server action and API route validates its input, for example with a schema library such as Zod.
• No secrets in client code, and only intentionally public values use the NEXT_PUBLIC_ prefix.
• No dangerouslySetInnerHTML with user content unless it is sanitized.
• Errors do not leak stack traces, queries or internal IDs to users.

What accessibility checks should a code review include?

Accessibility is much cheaper to fix in review than after launch:

• Interactive elements are real button or a elements, not clickable divs.
• Every form field has a label.
• Images have meaningful alt text, or empty alt if decorative.
• The feature works with a keyboard alone, with a visible focus state.
• Text and important UI meet contrast requirements.
• Headings follow a logical order.

Performance and tests

• Large dependencies are justified, and imported only where they are needed.
• Images use the Next.js Image component with sensible sizes.
• New logic with real business rules has tests. Not every line needs a test, but anything that would hurt if it broke does.

How should you write code review comments?

Explain why, suggest an alternative, and label the comment. My team uses Conventional Comments, a simple format that puts a label at the start of each comment:

suggestion (non-blocking): extract this into a useLeaveBalance hook,
the same calculation exists in two other components.

issue (blocking): this action never checks that the user belongs
to the organization, so any logged-in user could approve any leave.

nitpick (non-blocking): "data" -> "leaveRequests" would make this easier to scan.

praise: really nice job handling the empty state here.

The labels remove guesswork. The author knows exactly what must change before merging, and what is just a thought. Including praise matters too: review is also where people learn what good looks like.

How fast should code reviews happen?

Within one working day. Google’s engineering practices guide recommends responding within one business day, and in my experience that is the single biggest lever on team speed. Slow reviews block the author, push people toward huge pull requests, and pile up merge conflicts. My team blocks review time in the calendar so it happens reliably.

What should never be in a code review?

• Formatting debates. Prettier and ESLint settle those automatically.
• Personal preference presented as a rule. If it matters, add it to the team’s conventions instead.
• Rewriting the author’s solution in comments. Ask questions first.
• Comments about the person rather than the code.

Frequently asked questions

About the author

I’m Hardik Gohil, a Web Team Lead and Full-Stack Developer at ProLance IT in Surat, India. I review code every day for a team of 15+ developers working with React, Next.js, Node.js and NestJS. More on how the role changed my work: From Senior Developer to Team Lead: What Actually Changes.