Robert Honz
6d7f4f1625
* Enhanced wording for better understanding of blank line usage. * Clarified instructions on updating docstrings during refactoring. * Specified the use of line comments for complex logic explanations.
1.4 KiB
1.4 KiB
applyTo
| applyTo |
|---|
| **/*.py |
Project general coding standards
Naming Conventions
- Use snake_case for variable and function names.
- Use CamelCase for class names.
- Follow PEP 8 style guidelines.
- Prefix private class members with underscore (_).
- Use ALL_CAPS for constants.
Error Handling
- Use try/except blocks for async operations.
- Always log errors with contextual information.
Coding Guidelines
- Use type annotations / hints for function and method parameters, return types and variables. Follow PEP 484.
- Use the modern built-in generics from the
typingmodule, such aslist,dict, andset, instead of the olderList,Dict, andSetfromtyping. - Use newest coding style which is supported by the used Python version.
- Use more blank lines to achieve better code organization and readability.
- Follow PEP 492 – Coroutines with async and await syntax
- Follow PEP 498 – Literal String Interpolation
- Follow PEP 572 – Assignment Expressions
Code Documentation
- Always write doc strings for all modules, classes, functions, and methods using google docstring style.
- Use typing in doc strings.
- Use line comments to explain complex logic.
- If refactoring code, ensure to update or add doc strings accordingly.
- If refactoring code to not remove existing line comments, but to update them to reflect the new code logic.