9  AWE Coding Style

9.1 Project and repository organization

To support a consistent project setup, please refer to the AWE Python and MATLAB templates in the appendix.

9.2 Naming conventions

Type Naming Convention Examples
Function Use a lowercase word or words. Separate words by underscores to improve readability (snakecase). function, python_function
Variable Start each word with lowercase. Don’t separate words with underscores. This style is called mixedCase. x, var, pythonVariable
Class Start each word with a capital letter. Don’t separate words with underscores. This style is called CamelCase or Pascal case. Model, PythonClass
Method Use a lowercase word or words. Separate words with underscores to improve readability (snakecase). class_method, method
Constant Use an uppercase single letter, word, or words. Separate words with underscores to improve readability. CONSTANT, PYTHON_CONSTANT, PYTHON_LONG_CONSTANT
Module Use a short, lowercase word or words. Separate words with underscores to improve readability. module.py, python_module.py
Package Use a short, lowercase word or words. Don’t separate words with underscores. package, pythonpackage
Boolean Depends, if set by the user –> CONSTANT, if defined on runtime as variable. Always start with is_. isBoolean, IS_BOOLEAN

The following naming styles are commonly distinguished (from PEP 8):

  • b (single lowercase letter)
  • B (single uppercase letter)
  • lowercase
  • lower_case_with_underscores (snakecase)
  • UPPERCASE
  • UPPER_CASE_WITH_UNDERSCORES
  • CapitalizedWords (CamelCase) Note: When using acronyms in CapWords, capitalize all the letters of the acronym. Thus HTTPServerError is better than HttpServerError.
  • mixedCase (differs from CapitalizedWords by initial lowercase character!)
  • Capitalized_Words_With_Underscores (ugly!)

9.3 Docstring conventions

Sphinx can recognize the following docstring formats: