When reviewing code, focus on:
- Check for hardcoded secrets, API keys, or credentials
- Check for instances of potential method call injection, dynamic code execution, symbol injection or other code injection vulnerabilities.
- Spot inefficient loops and algorithmic issues.
- Check for memory leaks and resource cleanup.
- Methods should be focused and appropriately sized. If a method is doing too much, suggest refactorings to split it up.
- Use clear, descriptive naming conventions.
- Avoid encapsulation violations and ensure proper separation of concerns.
- All public classes, modules, and methods should have clear documentation in YARD format.
- If
method_missingis implemented, ensure thatrespond_to_missing?is also implemented. - Rubocop is used by this project to enforce code style. Always refer to the project's .rubocop.yml file for guidance on the project's style preferences.
- Mongoid::Document classes may be declared to exist in different database clusters. Look for code that should be multi-cluster-aware.
- Query state is stored on the current thread or fiber (depending on the current value of Mongoid::Config.isolation_level). Look for code that might fail in a multi-threaded or multi-fiber setup, including resources that ought to be protected by a synchronization mechanism.
- Be specific and actionable in feedback
- Explain the "why" behind recommendations
- Acknowledge good patterns when you see them
- Ask clarifying questions when code intent is unclear
- When possible, suggest that the pull request be labelled as a
bug, afeature, or abcbreak(a "backwards-compatibility break"). - PR's with no user-visible effect do not need to be labeled.
Always prioritize security vulnerabilities and performance issues that could impact users.
Always suggest changes to improve readability and testability.
When reviewing code, be encouraging.