Coding Conventions
TODO: update
DO NOT FORGET TESTS
Most style are enforced with the pre-commit hooks which automatically reformat the code and sort the imports. Code should follow PEP-8, particularly for naming conventions as these aren't modified by the pre-commit hooks.
Module Specifications
Depending on which module you are using, there could be rules to follow that are listed below.
| Module | Do | Do not |
|---|---|---|
| `pytest` | ||
| `datetime` | ||
| `SQL Alchemy` |
Structure
The following structures principles may also be followed:
__init__.pyshould not contain code, but__all__as a list- At a package level (routers for example) we have as few files as possible
- The package level
__init__.pyshould contain an empty__all__and the modules at that level should expose their respective public API - If the files have much in common (think of jobs, which have the sandbox, the joblogging, etc), we put them in a subpackage (e.g routers.job). The code goes in a specific file (job.py, joblogging.py)
- At subpackage level,
__init__.pyshould expose the public API through the__all__list by importing from the modules at that level. These submodules should not contain an__all__
See this issue.
Architecture
To make sure that each part of DiracX is doing only what it is supposed to do, you also need to follow these instructions:
diracx-routersshould deal with user interactions through HTTPs. It is expected to deal with permissions and should calldiracx-logic. Results returned should be translated into HTTP responses.diracx-logicshould embed Dirac specificities. It should encapsulate the logic of the services and should calldiracx-dbto interact with databases.diracx-dbshould contain atomic methods (complex logic is expected to be located indiracx-db).