Overview
A systematic approach to reviewing code changes, whether self-review before committing or reviewing others' pull requests.
When to Use
- Before committing code
- Reviewing pull requests
- Auditing existing code
- After making significant changes
Review Checklist
1. Correctness
- [ ] Does the code do what it's supposed to do?
- [ ] Are edge cases handled?
- [ ] Are there any obvious bugs?
- [ ] Do tests pass?
2. Security
- [ ] No hardcoded secrets or credentials
- [ ] Input validation present
- [ ] SQL injection prevention (parameterized queries)
- [ ] XSS prevention (output encoding)
- [ ] Authentication/authorization checks
3. Performance
- [ ] No N+1 query problems
- [ ] Appropriate caching
- [ ] No unnecessary loops or allocations
- [ ] Reasonable algorithmic complexity
4. Maintainability
- [ ] Clear naming (variables, functions, classes)
- [ ] Single responsibility (each function does one thing)
- [ ] No excessive complexity
- [ ] Reasonable file/function length
5. Testing
- [ ] Tests cover happy path
- [ ] Tests cover edge cases
- [ ] Tests are readable and maintainable
- [ ] No flaky tests
6. Documentation
- [ ] Complex logic is commented
- [ ] Public APIs are documented
- [ ] README updated if needed
Steps
- Understand the context - What problem is being solved?
- Read the diff - Understand what changed
- Run through checklist - Check each category
- Test locally - If significant changes
- Provide feedback - Be constructive and specific
Watch Out For
- Being too nitpicky about style (use linters)
- Missing the forest for the trees
- Not understanding the broader context
- Rubber-stamping without actually reviewing