code-review
Reviews code changes for architectural fitness, extensibility, and alignment with design principles. Use when reviewing code, checking PRs, or validating implementations.
Installation
Suivez les instructions du dépôt pour votre agent. Consultez les fichiers et dépendances avant l’installation.
Voir la source ↗GuidesInstructions
Code Review
Early-stage C++ compiler project. Primary goal: keep architecture clean and extensible.
Review Checklist
1. Architecture and Extensibility
- Does the change fit the intended structure and boundaries?
- If it doesn't fit existing abstractions, should we generalize the design?
- Will this scale as we add more features?
2. No Hacks or Special Cases
- Avoid patch-like solutions with feature-specific workarounds
- No scattered conditional logic ("just for this feature")
- If forcing something in, consider a better abstraction
3. Use Existing Utilities
- Don't reinvent what standard library or codebase already provides
- Use modern C++ when it improves clarity (not for fancy)
4. Error Handling
Check docs/error-handling.md for correct error type usage:
-
DiagnosticExceptiononly in AST→MIR (with source location) -
InternalErrorfor compiler bugs (MIR→LIR, codegen, unreachable code) -
std::runtime_errorfor interpreter/SDK runtime failures - Never use
std::unreachable()orDiagnosticException({})
5. Design Principles Alignment
Read docs/design-principles.md and check:
- No Workarounds
- Parameterize, Don't Specialize
- Capture Behavior at the Source
- Unify Before Multiplying
- Follow Established Patterns
- Use Domain Vocabulary
- Comments Explain Why, Not What
6. LIR Design (if touching LIR)
Check that LIR changes follow the correct mental model (see docs/architecture.md):
- Variable access: uses slang's flat symbol model (symbol = unique address, no instance traversal)
- Operations: RISC-V assembly style (register-based, explicit data flow)
-
Method calls on complex types: RISC-V function call style (object pointer as
this)
Output Format
- Summary: One sentence on what the change does
- Architecture: Impact on system structure, potential issues
- Concerns: Hacky patterns, violations of design principles
- Suggestions: Better abstractions if needed
Exemples
Consultez les exemples du dépôt source.
Voir la source ↗Historique source
- Date d’indexation
- 2026-01-20
- Mise à jour de l’index
- 2026-01-26
- Branch
- main
Les dates concernent ce répertoire. Consultez le dépôt pour l’historique du code.
GitHub ↗chat Comments (0)
Sign in to join the discussion and leave a comment.
No comments yet. Be the first to share your thoughts!