| | |
| | description: |
| | globs: |
| | alwaysApply: true |
| | |
| | |
| |
|
| | This document outlines the coding standards for the AI-powered database interface, emphasizing the use of English in all code-related content and adherence to SOLID principles, Clean Code, and Design Patterns. |
| |
|
| | |
| |
|
| | |
| | - All comments and notes must be written in English. |
| | - Avoid using any language other than English in code comments. |
| | - Ensure clarity and conciseness in comments to aid understanding. |
| |
|
| | |
| | - Use English for all variable and function names. |
| | - Follow a consistent naming convention (e.g., camelCase, snake_case). |
| | - Avoid using non-English characters or words in identifiers. |
| |
|
| | |
| | - All documentation, including README files and inline documentation, should be in English. |
| | - Ensure that all code examples and explanations are clear and accessible to English-speaking developers. |
| |
|
| | |
| |
|
| | |
| | - Write clear and descriptive comments. |
| | - Use meaningful variable and function names. |
| | - Maintain a consistent style throughout the codebase. |
| |
|
| | |
| | - Encourage team members to adhere to these standards. |
| | - Regular code reviews to ensure compliance with language consistency. |
| | - Provide feedback and support for maintaining these standards. |
| |
|
| | |
| |
|
| | |
| | - Each class should have only one reason to change. |
| | - Ensure that classes are focused on a single functionality. |
| |
|
| | |
| | - Software entities should be open for extension but closed for modification. |
| | - Use inheritance and polymorphism to extend functionality. |
| |
|
| | |
| | - Subtypes must be substitutable for their base types. |
| | - Ensure that derived classes can replace base classes without affecting the correctness of the program. |
| |
|
| | |
| | - Clients should not be forced to depend on interfaces they do not use. |
| | - Design interfaces to be specific to client needs. |
| |
|
| | |
| | - High-level modules should not depend on low-level modules. Both should depend on abstractions. |
| | - Use dependency injection to manage dependencies. |
| |
|
| | |
| |
|
| | |
| | - Use descriptive names for variables, functions, and classes. |
| | - Avoid abbreviations and unclear names. |
| |
|
| | |
| | - Functions should be small and do one thing. |
| | - Use descriptive names and avoid side effects. |
| |
|
| | |
| | - Comments should explain why, not what. |
| | - Avoid unnecessary comments and ensure they are up-to-date. |
| |
|
| | |
| | - Maintain consistent formatting and indentation. |
| | - Use whitespace effectively to improve readability. |
| |
|
| | |
| |
|
| | |
| | - Use patterns like Singleton, Factory, and Builder to manage object creation. |
| |
|
| | |
| | - Use patterns like Adapter, Bridge, and Composite to manage relationships between objects. |
| |
|
| | |
| | - Use patterns like Observer, Strategy, and Command to manage communication between objects. |
| |
|
| | |
| |
|
| | |
| | - Regular audits of the codebase to ensure adherence to language standards and design principles. |
| | - Address any deviations promptly to maintain consistency. |
| |
|
| | |
| | - Provide training and resources to help team members understand and follow these standards. |
| | - Encourage continuous learning and improvement in coding practices. |
| |
|