Python

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
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 troughtthrough gitlab registry,registry, avoiding the git+repo@branch form), this is allow correct versioning Network resources (ex. fileserver)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 have tomust 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,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.00))
Store semversioning in developments too, in files like setup.toml, .version and commits. To update new version easly,easily, you can use a tool called bumpversion (this is a guide made by lclementi) ColourAvoid 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