| name | code-review |
| description | Provides comprehensive code review guidance for React 19, Vue 3, Rust, TypeScript, Java, Python, and C/C++.
Helps catch bugs, improve code quality, and give constructive feedback.
Use when: reviewing pull requests, conducting PR reviews, code review, reviewing code changes,
establishing review standards, mentoring developers, architecture reviews, security audits,
checking code quality, finding bugs, giving feedback on code.
|
Code Review Excellence
Transform code reviews from gatekeeping to knowledge sharing through constructive feedback, systematic analysis, and collaborative improvement.
When to Use This Skill
- Reviewing pull requests and code changes
- Establishing code review standards for teams
- Mentoring junior developers through reviews
- Conducting architecture reviews
- Creating review checklists and guidelines
- Improving team collaboration
- Reducing code review cycle time
- Maintaining code quality standards
Core Principles
1. The Review Mindset
Goals of Code Review:
- Catch bugs and edge cases
- Ensure code maintainability
- Share knowledge across team
- Enforce coding standards
- Improve design and architecture
- Build team culture
Not the Goals:
- Show off knowledge
- Nitpick formatting (use linters)
- Block progress unnecessarily
- Rewrite to your preference
2. Effective Feedback
Good Feedback is:
- Specific and actionable
- Educational, not judgmental
- Focused on the code, not the person
- Balanced (praise good work too)
- Prioritized (critical vs nice-to-have)
[BAD] "This is wrong."
[GOOD] "This could cause a race condition when multiple users
access simultaneously. Consider using a mutex here."
[BAD] "Why didn't you use X pattern?"
[GOOD] "Have you considered the Repository pattern? It would
make this easier to test. Here's an example: [link]"
[BAD] "Rename this variable."
[GOOD] "[nit] Consider `userCount` instead of `uc` for
clarity. Not blocking if you prefer to keep it."
3. Review Scope
What to Review:
- Logic correctness and edge cases
- Security vulnerabilities
- Performance implications
- Test coverage and quality
- Error handling
- Documentation and comments
- API design and naming
- Architectural fit
What Not to Review Manually:
- Code formatting (use Prettier, Black, etc.)
- Import organization
- Linting violations
- Simple typos
Review Process
Phase 1: Context Gathering (2-3 minutes)
Before diving into code, understand:
- Read PR description and linked issue
- Check PR size (>400 lines? Ask to split)
- Review CI/CD status (tests passing?)
- Understand the business requirement
- Note any relevant architectural decisions
Phase 2: High-Level Review (5-10 minutes)
- Architecture & Design - Does the solution fit the problem?
- Performance Assessment - Are there performance concerns?
- File Organization - Are new files in the right places?
- Testing Strategy - Are there tests covering edge cases?
Phase 3: Line-by-Line Review (10-20 minutes)
For each file, check:
- Logic & Correctness - Edge cases, off-by-one, null checks, race conditions
- Security - Input validation, injection risks, XSS, sensitive data
- Performance - N+1 queries, unnecessary loops, memory leaks
- Maintainability - Clear names, single responsibility, comments
Phase 4: Summary & Decision (2-3 minutes)
- Summarize key concerns
- Highlight what you liked
- Make clear decision:
[approve] Approve[comment] Comment (minor suggestions)[changes] Request Changes (must address)
- Offer to pair if complex
Review Techniques
Technique 1: The Checklist Method
Use checklists for consistent reviews. See Security Review Guide for comprehensive security checklist.
Technique 2: The Question Approach
Instead of stating problems, ask questions:
[BAD] "This will fail if the list is empty."
[GOOD] "What happens if `items` is an empty array?"
[BAD] "You need error handling here."
[GOOD] "How should this behave if the API call fails?"
Technique 3: Suggest, Don't Command
Use collaborative language:
[BAD] "You must change this to use async/await"
[GOOD] "Suggestion: async/await might make this more readable. What do you think?"
[BAD] "Extract this into a function"
[GOOD] "This logic appears in 3 places. Would it make sense to extract it?"
Technique 4: Differentiate Severity
Use labels to indicate priority:
[blocking] - Must fix before merge[important] - Should fix, discuss if disagree[nit] - Nice to have, not blocking[suggestion] - Alternative approach to consider[learning] - Educational comment, no action needed[praise] - Good work, keep it up!
Language-Specific Guides
Consult the corresponding detailed guide based on the language being reviewed:
| Language/Framework | Reference File | Key Topics |
|---|
| React | React Guide | Hooks, useEffect, React 19 Actions, RSC, Suspense, TanStack Query v5 |
| Vue 3 | Vue Guide | Composition API, reactivity system, Props/Emits, Watchers, Composables |
| Rust | Rust Guide | Ownership/borrowing, Unsafe review, async code, error handling |
| TypeScript | TypeScript Guide | Type safety, async/await, immutability |
| Python | Python Guide | Mutable default arguments, exception handling, class attributes |
| Java | Java Guide | Java 17/21 features, Spring Boot 3, virtual threads, Stream/Optional |
| Go | Go Guide | Error handling, goroutine/channel, context, interface design |
| C | C Guide | Pointers/buffers, memory safety, UB, error handling |
| C++ | C++ Guide | RAII, lifetimes, Rule of 0/3/5, exception safety |
| CSS/Less/Sass | CSS Guide | Variable conventions, !important, performance, responsive design, compatibility |
| Qt | Qt Guide | Object model, signals/slots, memory management, thread safety, performance |
Additional Resources
