Style Guide for lambda-handlers¶
| Title: | Style Guide for lambda-handlers |
| Author(s): | Steffen Leistner, Alexandre Savio |
| Status: | Active |
| Type: | Process |
| Created: | 3-Nov-2019 |
| Updated: | 3-Nov-2019 |
Introduction¶
This document gives coding conventions for the lambda-handlers code comprising the project core as well as all official interfaces, extensions, and plugins for the framework. Optionally, projects that use lambda-handlers are encouraged to follow this documentation and link to it as a reference.
PEP 8 Foundation¶
All guidelines in this document are in addition to those defined in Python's PEP 8 and PEP 257 guidelines.
Line Length¶
Too short of lines discourage descriptive variable names where they otherwise make sense. Too long of lines reduce overall readability and make it hard to compare 2 files side by side. There is no perfect number: but for lambda-handlers, we've decided to cap the lines at 120 characters. We use a .editorconfig file to define this.
Descriptive Variable names¶
Naming things is hard. lambda-handlers has a few strict guidelines on the usage of variable names, which hopefully will reduce some of the guesswork:
- No one character variable names.
- Except for x, y, and z as coordinates.
- Avoid overriding built-in functions.
- Avoid Acronyms, Abbreviations, or any other short forms - unless they are almost universally understand.
Automated Code Cleaners¶
All code submitted to lambda-handlers should be formatted using Black and isort. Black should be run with the line length set to 120, and isort with Black compatible settings in place.
Automated Code Linting¶
All code submitted to hug should run through the following tools:
- Black and isort verification.
- Flake8,
- flake8-bugbear, and
- pep8-naming.