Coding Guidelines

Code Style

The Tryton Project strongly recommends the following code style:


Code style, in general, follows PEP 8 and PEP 257:

  • Use 4 spaces for indentation.
  • Avoid the usage of from M import *.
  • If unsure about conformity use flake8 to check the code (with option ignore=E123,E124,E126,E128,E741,W503) and isort to check the imports (with the parameters -m VERTICAL_GRID -p trytond).
  • Breaking lines:
    • Use 4 spaces per bracket pair.
    • Prefer parenthesis over backslash.
    • Prefer breaking lines after opening parenthesis.
  • Use double-quotes for strings that are natural language, single-quotes for symbol-like strings and triple double-quotes for multi-line docstrings.


  • Use 4 spaces for indentation.
  • No 80 columns limitation.
  • Opening tag on single line or one attribute per line.

Best Practices

These best practices help keep the code consistent:

  • Use doc-strings and comments in your code.
  • Never pass keyword arguments as positional arguments when calling a method.
  • In the very beginning (right under the doc-string) of a method definition, define all pool objects that will be used (pool.get(...)).

Naming of modules, classes, variables

  • A name should be as descriptive and as short as possible.
  • Avoid unnecessary duplication of names.
  • Naming structure of a model or module must follow these rules:
    • First part of the name is the general function of the module or model,
    • after this come the less general parts of the name (i.e. the more specific name parts) for the module or model
    • If you are unsure with naming, please ask first on the #tryton channel
  • For modules and method names use an underscore to separate the parts of name.
  • For naming classes use CamelCase.