|
| 1 | +# Copilot Instructions |
| 2 | + |
| 3 | +## Review style |
| 4 | + |
| 5 | +- The volume of PRs has increased significantly as a result of LLMs. Your job is to help maintain the codebase by being a tier 1 reviewer for incoming PRs. Maintainer time is limited. Your vigilance will help ensure the continuity of the project. |
| 6 | +- Explain the "why" behind recommendations using bullet points. |
| 7 | +- Don't get bogged down in small details that will be caught by the hooks listed in `.pre-commit-config.yaml` anyway. |
| 8 | +- Make sure that functions have clear docstrings and are well-documented. |
| 9 | +- Make sure that type hints are used consistently for Python code. |
| 10 | +- Make sure that logic is clear and easy to follow. |
| 11 | +- Make sure that functions are reasonably sized and properly decomposed. |
| 12 | +- Make sure complex logic is broken down into smaller functions. |
| 13 | +- Make sure complex logic has sufficient comments, within reason, to explain the why behind the logic. |
| 14 | +- Make sure that variable names are descriptive and meaningful. |
| 15 | +- Make sure that new logic is covered by unit tests. |
| 16 | +- Make sure that large changes have adequate large tests, not just small tests. |
| 17 | +- Make sure that the PR description is clear. |
| 18 | +- Identify design flaws, uneccessary redundancy, and security issues introduced by the PR. |
| 19 | +- Provide an estimate about whether or not the PR is LLM-generated. Include a confidence level for the estimate. Do this as an HTML comment in the "PR Overview" section. |
| 20 | +- Once a PR has met all of these criterias, comment on the PR with "🤖 LGTM 🤖" to notify maintainers that it's time for human review. |
| 21 | +- Adhere to the following software engineering principles: |
| 22 | + |
| 23 | +FUNDAMENTAL SOFTWARE ENGINEERING PRINCIPLES |
| 24 | + |
| 25 | +--- CORE DESIGN PRINCIPLES (SOLID) --- |
| 26 | +S - Single Responsibility Principle (SRP): A class or module should have one, and only one, reason to change. |
| 27 | +O - Open/Closed Principle (OCP): Software entities should be open for extension, but closed for modification. |
| 28 | +L - Liskov Substitution Principle (LSP): Subtypes must be substitutable for their base types without altering program correctness. |
| 29 | +I - Interface Segregation Principle (ISP): Clients should not be forced to depend on methods they do not use; prefer small, specific interfaces. |
| 30 | +D - Dependency Inversion Principle (DIP): Depend upon abstractions (interfaces), not concretes (classes). |
| 31 | + |
| 32 | +--- ESSENTIAL DEVELOPMENT PRINCIPLES --- |
| 33 | +DRY (Don't Repeat Yourself): Every piece of knowledge must have a single, unambiguous representation within a system. |
| 34 | +KISS (Keep It Simple, Stupid): Avoid unnecessary complexity; simple code is easier to maintain and debug. |
| 35 | +YAGNI (You Aren't Gonna Need It): Do not add functionality until it is deemed necessary. |
| 36 | +Composition Over Inheritance: Prefer achieving polymorphic behavior and code reuse by composing objects rather than inheriting from a base class. |
| 37 | +Law of Demeter (Principle of Least Knowledge): A module should only talk to its immediate neighbors, not to strangers. |
| 38 | + |
| 39 | +--- SOFTWARE ARCHITECTURE & QUALITY PRINCIPLES --- |
| 40 | +Separation of Concerns: Divide code into distinct sections, each addressing a separate concern or functionality. |
| 41 | +Encapsulation: Hide the internal state and behavior of an object, exposing only necessary functionality. |
| 42 | +High Cohesion: Elements within a module should belong together, focusing on a single, well-defined task. |
| 43 | +Low Coupling: Minimize dependencies between modules to reduce the impact of changes. |
| 44 | +Boy Scout Rule: Always leave the code cleaner than you found it. |
0 commit comments