Code Review Checklist

One review answers a single question: "Will this code become someone else's problem within three months?" Walk the five axes in order; each axis gets pass / fail / N-A, and every failure must come with a concrete fix.

Workflow

1. Check the scope first: look at the diff size. Over ~400 changed lines, ask for a split before reviewing — review quality on huge diffs always collapses.
2. Check axis by axis (order = priority):
   • Correctness: edge cases (null, empty, zero, negative, oversized), concurrency/timing assumptions, error handling (are exceptions swallowed?). The only axis that can block a merge.
   • Security: is user input concatenated into SQL / shell commands / HTML; are secrets or tokens hard-coded; does logging leak sensitive data.
   • Readability: do names say what things are; does each function do one thing; are magic numbers named. Flag only what you can't understand — not "I'd write it differently."
   • Performance: repeated queries or recomputation inside loops; N+1 problems; avoidable large-object copies. No data-free performance speculation ("this might get slow" is not a comment).
   • Test coverage: does new logic have tests; do edge cases have cases. All-green tests with the critical path uncovered still get sent back.
3. Write the comments: fixed format — [axis] file:line problem → suggested fix. Only actionable suggestions; "could be optimized" is not one.
4. Triage: Must fix (correctness / security) vs Should fix (readability / performance / tests). "Should fix" doesn't block the merge, but say so explicitly.

Rules