|
| 1 | +# MyCoder PR Review Guidelines |
| 2 | + |
| 3 | +This document outlines the criteria and guidelines that MyCoder uses when reviewing pull requests. These guidelines help ensure that contributions maintain high quality and consistency with the project's standards. |
| 4 | + |
| 5 | +## Issue Alignment |
| 6 | + |
| 7 | +- Does the PR directly address the requirements specified in the linked issue? |
| 8 | +- Are all the requirements from the original issue satisfied? |
| 9 | +- Does the PR consider points raised in the issue discussion? |
| 10 | +- Is there any scope creep (changes not related to the original issue)? |
| 11 | + |
| 12 | +## Code Quality |
| 13 | + |
| 14 | +- **Clean Design**: Is the code design clear and not overly complex? |
| 15 | +- **Terseness**: Is the code concise without sacrificing readability? |
| 16 | +- **Duplication**: Does the code avoid duplication? Are there opportunities to reuse existing code? |
| 17 | +- **Consistency**: Does the code follow the same patterns and organization as the rest of the project? |
| 18 | +- **Naming**: Are variables, functions, and classes named clearly and consistently? |
| 19 | +- **Comments**: Are complex sections adequately commented? Are there unnecessary comments? |
| 20 | + |
| 21 | +## Function and Component Design |
| 22 | + |
| 23 | +- **Single Responsibility**: Does each function or component have a clear, single purpose? |
| 24 | +- **Parameter Count**: Do functions have a reasonable number of parameters? |
| 25 | +- **Return Values**: Are return values consistent and well-documented? |
| 26 | +- **Error Handling**: Is error handling comprehensive and consistent? |
| 27 | +- **Side Effects**: Are side effects minimized and documented where necessary? |
| 28 | + |
| 29 | +## Testing |
| 30 | + |
| 31 | +- Are there appropriate tests for new functionality? |
| 32 | +- Do the tests cover edge cases and potential failure scenarios? |
| 33 | +- Are the tests readable and maintainable? |
| 34 | + |
| 35 | +## Documentation |
| 36 | + |
| 37 | +- Is new functionality properly documented? |
| 38 | +- Are changes to existing APIs documented? |
| 39 | +- Are README or other documentation files updated if necessary? |
| 40 | + |
| 41 | +## Performance Considerations |
| 42 | + |
| 43 | +- Are there any potential performance issues? |
| 44 | +- For computationally intensive operations, have alternatives been considered? |
| 45 | + |
| 46 | +## Security Considerations |
| 47 | + |
| 48 | +- Does the code introduce any security vulnerabilities? |
| 49 | +- Is user input properly validated and sanitized? |
| 50 | +- Are credentials and sensitive data handled securely? |
| 51 | + |
| 52 | +## Accessibility |
| 53 | + |
| 54 | +- Do UI changes maintain or improve accessibility? |
| 55 | +- Are there appropriate ARIA attributes where needed? |
| 56 | + |
| 57 | +## Browser/Environment Compatibility |
| 58 | + |
| 59 | +- Will the changes work across all supported browsers/environments? |
| 60 | +- Are there any platform-specific considerations that need addressing? |
| 61 | + |
| 62 | +## Follow-up Review Guidelines |
| 63 | + |
| 64 | +When reviewing updates to a PR: |
| 65 | + |
| 66 | +- Focus on whether previous feedback has been addressed |
| 67 | +- Acknowledge improvements and progress |
| 68 | +- Provide constructive guidance for any remaining issues |
| 69 | +- Be encouraging and solution-oriented |
| 70 | +- Avoid repeating previous feedback unless clarification is needed |
| 71 | +- Help move the PR towards completion rather than finding new issues |
| 72 | + |
| 73 | +Remember that the goal is to help improve the code while maintaining a positive and constructive environment for all contributors. |
0 commit comments