You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
To maintain high-quality code and ensure consistency across the entire COSMOS project, we have established coding standards and conventions. This document outlines the key standards and practices that all contributors are expected to follow. Adhering to these guidelines helps us to achieve a codebase that appears as if it were written by a single entity, regardless of the number of contributors.
5
+
6
+
## Coding Standards
7
+
8
+
### Formatting Standards
9
+
-**Line Length**: Maximum of 120 characters per line to ensure readability across various environments.
10
+
-**Code Formatting**: Utilize tools like Black for Python code to ensure consistent formatting across the entire codebase.
11
+
-**Import Ordering**: Follow a consistent import order:
12
+
- Standard library imports.
13
+
- Third-party imports.
14
+
- Application-specific imports.
15
+
16
+
### Naming Conventions
17
+
-**Variables and Functions**: Use `snake_case`.
18
+
-**Classes and Exceptions**: Use `CamelCase`.
19
+
-**Constants**: Use `UPPER_CASE`.
20
+
21
+
### Commenting
22
+
- Inline comments should be used sparingly and only when necessary to explain "why" something is done, not "what" is done.
23
+
- All public methods, classes, and modules should include docstrings that follow the [Google style guide](https://google.github.io/styleguide/pyguide.html).
24
+
25
+
### Error Handling
26
+
- Explicit is better than implicit. Raise exceptions rather than returning None or any error codes.
27
+
- Use custom exceptions over generic exceptions when possible to make error handling more predictive.
28
+
29
+
## Tool Configurations and Pre-commit Hooks
30
+
31
+
To automate and enforce these standards, the following tools are configured with pre-commit hooks in our development process:
32
+
33
+
### Pre-commit Hooks Setup
34
+
35
+
To ensure that these tools are run automatically on every commit, contributors must set up pre-commit hooks locally. Run the following commands to install and configure pre-commit hooks:
36
+
37
+
```bash
38
+
pip install pre-commit
39
+
pre-commit install
40
+
pre-commit run --all-files
41
+
```
42
+
43
+
The following pre-commit hooks are configured:
44
+
45
+
- trailing-whitespace, end-of-file-fixer, check-yaml, check-merge-conflict, debug-statements: Checks for common formatting issues.
46
+
- pyupgrade: Automatically upgrades syntax for newer versions of the language.
47
+
- black: Formats Python code to ensure consistent styling.
48
+
- isort: Sorts imports alphabetically and automatically separated into sections.
49
+
- flake8: Lints code to catch styling errors and potential bugs.
50
+
- mypy: Checks type annotations to catch potential bugs.
51
+
- bandit: Scans code for common security issues.
52
+
- gitleaks: Prevents secrets from being committed to the repository.
53
+
- hadolint: Lints Dockerfiles to ensure best practices and common conventions are followed.
54
+
55
+
## Continuous Integration (CI)
56
+
When a commit is pushed to a branch that is part of a Pull Request, our Continuous Integration (CI) pipeline automatically runs specified tools to check code quality, style, security and other standards. If these checks fail, the PR cannot be merged until all issues are resolved.
57
+
58
+
## Quality Standards Enforcement
59
+
- PRs must pass all checks from the configured pre-commit hooks and CI pipeline to be eligible for merging.
60
+
- Code reviews additionally focus on logical errors and code quality beyond what automated tools can detect.
61
+
62
+
## Conclusion
63
+
By adhering to these standards and utilizing the tools set up, we maintain the high quality and consistency of our codebase, making it easier for developers to collaborate effectively.
0 commit comments