Review Criteria
This reference document outlines the criteria to prioritize when performing a code review, as well as guidelines for severity and constraints to ensure high-quality feedback.
Prioritized Criteria
1. Correctness
Verify code functionality, handle edge cases, and ensure alignment between function descriptions and implementations.
- Logic errors: Check for flawed logic or incorrect algorithms.
- Error handling: Ensure errors are handled gracefully and not swallowed.
- Race conditions: Look for potential concurrency issues.
- Data validation: Verify that inputs are validated correctly.
- API usage: Ensure APIs are used correctly and efficiently.
2. Efficiency
Identify performance bottlenecks and optimize for efficiency.
- Avoid unnecessary loops, iterations, or calculations.
- Watch for memory leaks or inefficient data structures.
- Avoid excessive logging in performance-critical paths.
3. Maintainability
Assess code readability, modularity, and adherence to language idioms.
- Naming: Ensure variables, functions, and classes have descriptive names.
- Complexity: Identify overly complex functions that should be refactored.
- Code duplication: Look for opportunities to reuse code.
- Style: Adhere to specified style guides. Violations should be noted.
- Style Guide Conflict: If Organization-level and Repository-level style guides conflict, always prefer and enforce the rule specified in the Repository-level style guide.
4. Security
Identify potential vulnerabilities.
- Insecure storage of sensitive data.
- Injection attacks (SQL, command, etc.).
- Insufficient access controls or validation.
Severity Levels
Use these severity levels to categorize your findings:
- critical: Must be addressed immediately. Could lead to serious consequences for correctness, security, or performance.
- high: Should be addressed soon. Likely to cause problems in the future.
- medium: Should be considered for future improvement. Not critical or urgent.
- low: Minor or stylistic issues. Can be addressed at the author's discretion.
Critical Constraints
- Only comment on changed lines: Your comments should only refer to lines that begin with a
+or-character in the diff. - No fluff: DO NOT add review comments to tell the user that they made a "good" or "appropriate" improvement. Only comment when there is an improvement opportunity.
- No explanations: DO NOT add review comments to explain what the code change does or validate that it works. The author knows what they wrote.
- Succinct suggestions: Aim to make code suggestions succinct and directly applicable.
- Compilable suggestions: Ensure code suggestions are valid code snippets that can be directly applied.