Code Review Checklist

Code Review Checklist guides an actionable review across correctness, security, readability, performance and test coverage. The review asks whether the code is likely to become a maintenance problem within three months. Each axis receives pass, fail or N-A, and a failure requires a concrete fix.

The workflow checks scope before detailed review. A diff above roughly 400 changed lines should be split so review remains manageable. It then visits the axes in priority order, beginning with correctness. Edge cases include null, empty, zero, negative and oversized values. Timing assumptions, concurrency and swallowed exceptions are part of this first pass.

Security checks examine user-input concatenation into SQL, shell commands or HTML, hard-coded secrets and tokens, and sensitive data exposed in logs. Readability focuses on understandable names, single-purpose functions and named constants rather than personal preferences. Performance examines repeated queries, recomputation in loops, N+1 patterns and avoidable large-object copies. A performance concern requires evidence instead of speculation.

Test coverage checks whether new logic and relevant edge cases are covered. Passing tests do not compensate for an uncovered critical path. The workflow calls for returning such a change for coverage rather than accepting a green test result alone.

Use it when reviewing code, a diff or a pull request and the result should be actionable without style nitpicks. Indentation, quote preferences and semicolons belong to the linter rather than review comments.

The checklist is a heuristic, not proof of correctness, security or speed. Specialist questions such as financial rounding, protocol conformance or accessibility need additional domain review. The security axis is a reading checklist; static analysis, dependency auditing and secret scanning remain separate tools. Reviewing a diff cannot establish that every requirement was met.

Input is the actual diff and enough code context to substantiate each finding. Comments use an axis, file and line, problem, and suggested fix. A comment without a concrete code reference is invalid. Vague statements about optimization do not meet the format.

Triage distinguishes Must fix findings in correctness or security from Should fix findings in readability, performance or tests. The workflow identifies correctness as its merge-blocking axis and explicitly describes Should fix comments as nonblocking. Findings remain tied to the examined lines rather than a generic approval.

A supplied comment example is:

[Must fix][Correctness] order.py:87 empty order list triggers IndexError → guard for empty before taking [0]
[Should fix][Readability] order.py:92 magic number 86400 → name it SECONDS_PER_DAY

A review has at most ten comments. If problems exceed a manageable review, the appropriate result is a rewrite and resubmission rather than a long grading exercise. An empty findings list means no finding was evidenced in the reviewed scope; it does not establish that the whole change is safe or complete.