| # 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. |
