Code Review

# ===== The goal =====
# Catch bugs, share knowledge, raise the quality bar.
# Without slowing the team down.

# ===== Author responsibilities =====
# 1. Small PRs (< 400 lines diff)
# 2. Self-review before requesting review
# 3. Clear PR description (what + why)
# 4. Test plan in the PR body
# 5. Respond to every comment
# 6. Re-request review after fixes

# ===== Reviewer responsibilities =====
# 1. Within 1 business day (or the team's SLA)
# 2. Read the PR description first
# 3. Check the diff with empathy + curiosity
# 4. Distinguish must-fix from nit
# 5. Suggest concrete fixes, not just complaints

# ===== Comment types =====
# Block (request changes): must fix
# Suggestion: pointed inline diff
# Question: 'why this approach?'
# Nit: stylistic preference; non-blocking
# Praise: 'nice solution!' (do this more)

# Prefix nits clearly:
# 'nit: prefer .find over .filter()[0] here'

# ===== Inline suggestion =====
# GitHub / GitLab: in the review comment, use:
\`\`\`suggestion
const total = subtotal + tax;
\`\`\`
# Author can accept with one click.

# ===== Patterns to internalise =====
# - Read the description before the diff
# - Ask questions before suggesting changes
# - Be specific: 'rename X to Y because ...'
# - Approve with comments if there are no blockers
# - Pair-review for complex changes (call, screen share)

# ===== Anti-patterns =====
# - 'LGTM' without reading
# - Bike-shedding on style (use a formatter)
# - Long PR threads with no resolution
# - Ghost reviews (mark as approved but never read)
# - Hostile language; 'you ...' -> 'we could ...'

# ===== Pre-PR self-review checklist =====
# - [ ] Tests added or updated
# - [ ] No console.log / debugger left
# - [ ] Variable names clear
# - [ ] Public API changes documented
# - [ ] No secrets / .env / large binaries
# - [ ] Performance considered (N+1, hot loops)
# - [ ] Accessibility for UI changes
# - [ ] Security: input validation, auth checks

# ===== Tools =====
# GitHub PR review interface (inline + suggestions)
# Gerrit (Google-style review queue + +1/+2 system)
# Reviewable (richer GitHub-attached UI)
# Phabricator (legacy but loved by some teams)

# ===== Branch protection =====
# Require N approvals before merge
# Require CI green
# Dismiss stale reviews on push
# Require linear history
# Restrict who can merge

# ===== Cultural habits =====
# - Reviewer first on the PR; author updates after each round
# - 'I tested this manually + the test plan says ...'
# - Pair-program on PRs that change complex code paths
# - Rotate review duty so no one becomes the gate
# - Praise good patterns publicly; correct privately when needed

# ===== Pitfalls =====
# - Mega-PRs (> 1000 lines) -> nobody reviews properly
# - Review-as-gatekeeping ('I won't approve until X')
# - Review without understanding (silence is worse than questions)
# - Mixing formatting + logic changes in one PR

# Aim for small, focused PRs (<400 lines).
# Review for correctness, design, tests, and naming.