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.