Code Review Guidelines
This guide defines how the reviewer evaluates a pull request.
Baseline Assumptions
- The code compiles.
- All tests pass.
Normative Words
- MUST: Mandatory. Not following this is a violation of the guide.
- MUST NOT: Forbidden.
- SHOULD: Recommended in almost all cases; exceptions need a strong reason.
- SHOULD NOT: Generally discouraged; only do it with clear justification.
- MAY: Optional; use judgment.
Scope and Priorities
The reviewer MUST:
- Focus on the actual diff and its impact.
- Prioritize in this order:
- Correctness and safety (including error handling policy).
- Public API and external behavior.
- Concurrency and performance issues with real impact.
- Readability, idioms, maintainability.
The reviewer MUST NOT:
- Invent business logic or protocol rules not implied by the code or docs.
- Demand large unrelated refactors unless there is a clear correctness or safety concern.
Review Process
- Read the PR description and understand the intent
- Review the diff file by file
- For each change, consider:
- Does this introduce bugs or security issues?
- Is the API appropriate?
- Are edge cases handled?
- Is error handling adequate?
- Provide actionable, specific feedback
- Distinguish blocking issues from suggestions
Feedback Format
Use clear prefixes:
- MUST FIX: Blocking issue that needs resolution
- SHOULD FIX: Strong recommendation
- CONSIDER: Optional improvement
- QUESTION: Clarification needed