Code Review Checklist Generator

Every review should check: correctness (does the logic match the spec?), edge cases (null, empty, overflow, off-by-one), security (injection, auth, data exposure), performance (unnecessary queries, missing indexes, O(n²) where O(n) is needed), readability (names, comments, complexity), and test coverage (is new logic tested?). Use a checklist to ensure nothing is skipped under time pressure.

Research by SmartBear found reviewers find 70–90% of defects in PRs under 400 lines. Above 400 lines, defect detection drops and review takes disproportionately longer. Aim for PRs under 300 lines changed. If a feature requires more, split into a stack of dependent PRs: infrastructure → logic → UI → tests.

Use the Conventional Comment format: prefix comments with labels like 'nit: (optional style suggestion)', 'question: (asking for clarification)', 'suggestion: (not blocking)', 'issue: (must fix)', 'blocking: (cannot merge)'. This makes intent clear and reduces misunderstandings. Praise good patterns explicitly — 'nice use of the strategy pattern here'.

Don't: review for style (use linters/formatters instead), bikeshed on personal preferences, rewrite code in a different style just because you'd write it differently, review the same issue in multiple comments, or delay reviews causing merge conflicts. Do: ask questions not accusations, acknowledge tradeoffs, approve with nits if overall direction is correct.

Automated tools handle objective checks so humans can focus on logic and design: ESLint/TSLint (style, bugs), TypeScript (type safety), Snyk/Dependabot (security), SonarQube (code smells, complexity), Codecov (test coverage), and GitHub Actions (CI tests). A good policy: PRs can only be reviewed by humans after all automated checks pass.