| name | my-code-review |
| description | Code review principles and checklist for reviewing any codebase regardless of language. Use when the user asks to review code, perform a code review, assess a pull request, or evaluate code quality across design, tests, performance, security, and correctness. |
Code Review
Based on "What to look for in a code review" by Trisha Gee (Java Champion, JetBrains) and personal notes
When to use
- User asks to review code or a pull request
- User asks for a code review checklist
- User wants to assess the quality of a change
- User mentions design, readability, test coverage, security, or correctness concerns
Overview
A structured, language-agnostic checklist to guide thorough code reviews. Reviews should reduce cognitive load, catch correctness issues, and share knowledge — not just find bugs.
Rules
Design
- Architecture fit — Does the change align with the overall architecture and existing conventions?
- SOLID — Are Single Responsibility, Open/Closed, Liskov, Interface Segregation, and Dependency Inversion respected?
- DDD — Are domain concepts clearly named and properly modelled?
- YAGNI / KISS — No speculative generality; prefer the simplest solution that works
- Code reuse — Is there a refactoring or extraction opportunity to avoid duplication?
Readability & Maintainability
- Understandability — Can a new reader understand the intent without context?
- Naming — Are names precise, consistent, and self-documenting?
- Happy path vs exceptional cases — Are both paths handled explicitly and clearly?