Code Review Skill
Overview
This skill provides a systematic approach to code review, ensuring thorough quality assessment while maintaining constructive feedback practices.
Review Checklist
Code Quality
- • Code is readable and self-documenting
- • Functions are small and focused (< 50 lines)
- • Variable names are descriptive
- • No unnecessary complexity
- • DRY principle followed
- • Consistent formatting
Logic & Correctness
- • Logic is sound and correct
- • Edge cases handled
- • Boundary conditions checked
- • No off-by-one errors
- • Return values are correct
- • State mutations are intentional
Error Handling
- • All error cases handled
- • Error messages are helpful
- • No silent failures
- • Async errors are caught
- • Errors don't leak sensitive info
Security (OWASP Top 10)
- • No hardcoded credentials
- • Input is validated/sanitized
- • No injection vulnerabilities (SQL, XSS, command)
- • Authentication/authorization proper
- • Sensitive data protected
Performance
- • No obvious inefficiencies
- • Appropriate data structures
- • No N+1 query patterns
- • Unnecessary operations avoided
- • Memory leaks prevented
Testing
- • Tests exist for new code
- • Tests cover happy path
- • Tests cover edge cases
- • Tests cover error cases
- • Tests are maintainable
Documentation
- • Complex logic explained
- • Public APIs documented
- • No outdated comments
- • README updated if needed
Review Process
Step 1: Understand Context
- •Read the PR description
- •Understand the purpose
- •Check related issues/tickets
- •Review the overall approach
Step 2: High-Level Review
- •Does the approach make sense?
- •Are there architectural concerns?
- •Is it the right solution?
- •Are there simpler alternatives?
Step 3: Detailed Review
- •Go through each file
- •Check against checklist
- •Note issues with severity
- •Provide specific feedback
Step 4: Summarize
- •Categorize findings
- •Prioritize issues
- •Acknowledge good work
- •Provide clear recommendations
Severity Levels
| Level | Description | Action Required |
|---|---|---|
| Blocker | Security risk, crashes | Must fix before merge |
| Critical | Bugs, broken functionality | Must fix |
| Major | Code quality issues | Should fix |
| Minor | Style, suggestions | Nice to have |
| Info | Questions, discussion | FYI only |
Feedback Guidelines
Good Feedback
markdown
# Constructive
"This function is getting complex. Consider extracting the validation
logic into a separate `validateInput()` function for better readability."
# Specific with solution
"Line 45: This SQL query is vulnerable to injection. Consider using
parameterized queries:
`const result = await db.query('SELECT * FROM users WHERE id = ?', [userId]);`"
# Educational
"Nice use of early returns here! For consistency, consider applying
the same pattern in the `processOrder` function above."
Bad Feedback
markdown
# Vague "This could be better." # No solution "This is wrong." # Harsh "This is terrible code. Did you even test this?" # Nitpicking "Use single quotes instead of double quotes." (When both are acceptable in the project)
Review Report Template
markdown
# Code Review Report **PR/Commit**: [Reference] **Reviewer**: [Name] **Date**: [Date] ## Summary | Severity | Count | |----------|-------| | Blocker | X | | Critical | X | | Major | X | | Minor | X | **Verdict**: Approve / Request Changes / Needs Discussion ## Findings ### Blockers [None / List items] ### Critical [None / List items] ### Major [None / List items] ### Minor [None / List items] ## What's Good - [Positive observation 1] - [Positive observation 2] ## Recommendations 1. [Action item] 2. [Action item]
Common Issues to Catch
Security
- •Hardcoded secrets
- •SQL injection
- •XSS vulnerabilities
- •Missing authentication
- •Insecure direct object references
Performance
- •N+1 database queries
- •Missing indexes
- •Large synchronous operations
- •Memory leaks
- •Unnecessary API calls
Reliability
- •Missing error handling
- •Race conditions
- •Undefined behavior on edge cases
- •No input validation
- •Silent failures
Maintainability
- •Code duplication
- •God functions (too long)
- •Unclear naming
- •Missing documentation
- •Complex conditionals
Self-Review Before PR
Authors should check:
- • Tests pass locally
- • Code is formatted
- • No debug code left
- • Self-reviewed the diff
- • PR description is clear
- • Related issues linked