This is a list of best practices to be applied in developments with the goal of increasing the standardization of our code and quality:
The main set of conventions used in Python is PEP8
The following naming conventions are used: lowercase x packages, uppercase x constants, snakecase x modules, functions and variables, pascalcase x classes
On function definition you must specify parameters and return type
The inline docs follow the Google docs which has exaplanation, args, return and exception fields
Imports must be alfabetically ordered, splitted in 3 sections(standard, third part, local) and separated by a blank line
A row has a maximum lenght of 79 columns
Every module's scope function and class must be surrounded by 2 blank lines. The class's scope function only by 1
Strings should always be enclosed in double quotes
Path must be handled with pathlib.Path to have correct evaluation in different systems
Always use logger instead of print, to have a more structured visibility of the execution
Handling max login attempts in scraping, with a notify (ex, email) to avoid credential blacklisting and alert users
Install private packages through gitlab registry, avoiding the git+repo@branch form), this is allow correct versioning
Network resources (ex. fileserver) could not always be available. On script's startup, test the connectivity, if there's somethings wrong, then send an alert to our team. However, you should save the files locally
As documentation, a README file is a description of the development with the POV of a developer, so you must describe the core mechanism of the script and known errors or bug
To prevent the library update from creating a development malfunction, specify in the requirements.txt the version used
The core code must be stored in "src" folder, to optimize organization and module importing
When a development is ready to be released or have to be updated in remote environments, always write/update a secret note in bitwarden named "env_{COLL/DEV/PROD}_{automation_code}_{automation_name}"
Writing unit test to avoid change request/bug resolution/refactor from creating a development malfunction. This can be done easily writing atomic functions and test every core function of the development
Package versioning tags are a key to release correct versions for different scopes (ex. 1.0.0.dev, 1.0.0)
Store semversioning in developments too, in files like setup.toml, .version and commits. To update new version easily, you can use a tool called bumpversion (this is a guide made by lclementi)
Avoid colour formatter to get a cleaner visibility in Grafana
Use a common formatter for logging: "%(asctime)s - %(name)s - %(levelname)s - %(message)s" with thread_name if needed
Every development needs to be added in UptimeKuma which alert if it is not available. For webapp we can add the dns to ping it. For scheduled processes we have to add a GET request to ping the monitoring system when run is success.
No Comments