# Code Review

> Systematic review of code changes for correctness, security, performance, and maintainability.

## When to Use
- Pull request review
- Pre-merge code inspection
- "Review this code" or "check this PR"

## Approach
1. **Read the PR description first** — understand intent before reading code
2. **Check tests first** — if tests are missing or weak, flag before reviewing implementation
3. **Scan for security issues** — injection, auth bypass, exposed secrets, unsafe deserialization
4. **Check error handling** — every external call, every parse, every file operation needs error handling
5. **Look for missing edge cases** — null inputs, empty collections, concurrent access, boundary values
6. **Assess naming and clarity** — code is read 10x more than it's written
7. **Check for unintended side effects** — does this change break anything outside its scope?

## Output Format
Use a findings table:

| Severity | File:Line | Issue | Suggestion |
|----------|-----------|-------|------------|
| Critical | auth.py:45 | SQL injection via string interpolation | Use parameterized query |
| Warning | utils.py:12 | No error handling on HTTP call | Wrap in try/except |
| Nit | config.py:3 | Magic number 86400 | Use named constant SECONDS_PER_DAY |

## Common Mistakes
- Reviewing style before substance — correctness and security first, style last
- Missing the forest for the trees — check architectural fit, not just line-by-line
- Not running the code mentally — trace the execution path for the main use case
- Forgetting to check what was NOT changed — sometimes the bug is in code the PR didn't touch

## Quality Indicators
- All critical/high findings have specific fix suggestions
- Positive feedback included ("good use of X" — reinforcement matters)
- Findings prioritized by severity, not by order discovered
