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


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.