Coding Style Guidelines

HEPCloud Decision Engine Python Style Guide

The goal of this style guide is to help produce clear, consistent, and correct Python code. We have based our guidelines on the Google Python Style Guidelines which are themselves based on PEP 8. The Black code formatter is also applied to the code to further improve consistency.

Modifications to the Google style guidelines

3.9 Classes

In Python 3, classes implicitly inherit from object, so there is no need to do this explicitly.

Additions to the Google style guidelines

Getters/setters

In classes that maintain no invariants, use public instance variables, and do not write accessor (getter/setter) methods.

Private members/data

In classes that maintain one or more invariants, use a single underscore to mark data as private. While this is only a notational indication, not enforced by the Python interpreter, it makes it clear to the user what is intended for use outside the class, and what is not.

Imports

Do

from decisionengine.framework.dataspace import dataspace

not

import decisionengine.framework.dataspace as dataspace

and never:

from decisionengine.framework.dataspace import *

Loops/conditional statements

Reinforcing 3.14. Generally only one statement per line. Loops/conditional blocks should not be one-liners:

Do:

if foo :
  baz()

for _ in range(10):
  baz()

rather than:

if foo: baz()

for _ in range(10): baz()

Class names

Following PEP8 CamelStyle class names. No underscores. If the class name should contain an acronym capitalize only the first letter, like so:

class GceBillingCalculator

(this is mostly for uniformity and better readability)

Produce/Consume key names:

PRODUCES = ["Gce_Burn_Rate"]

as opposed to

PRODUCES = ["GCE_Burn_Rate"]