code-review-patterns

# Code Review Patterns ## The Goal of Code Review Code review is NOT about finding mistakes to win arguments. It is about: 1. **Correctness** — Does the code do what it's supposed to do? 2. **Safety** — Are there security or data integrity risks? 3. **Clarity** — Will the next developer understand this in 6 months? 4. **Consistency** — Does this follow the established patterns in the codebase? ## What to Look For — Priority Order ### P0 — Block (must fix before merge) ``` □ Security vulnerability (SQL injection, XSS, auth bypass, hardcoded secrets) □ Data loss risk (wrong delete scope, missing transaction, no backup) □ Correctness bug (wrong logic, off-by-one, race condition) □ Broken tests or test coverage dropped below 80% □ Deployment risk (migration without rollback, breaking API change) ``` ### P1 — Should Fix ``` □ Missing error handling (silent catch, swallowed exception) □ N+1 query problem □ Function over 50 lines (extract responsibility) □ File over 800 lines (extract module) □ Nesting depth > 4 (use early returns) □ Missing input validation on public endpoints □ console.log / debug statements left in □ TODO comments without tracking issue ``` ### P2 — Consider Fixing ``` □ Naming: unclear variable/function names □ Missing comments on non-obvious logic □ Magic numbers (use named constants) □ Duplicate code (extract utility) □ Missing type annotations ``` ### P3 — Optional / Style ``` □ Formatting inconsistency (should be caught by linter/prettier) □ Minor nam...