Linting

We use ruff to lint our Python code. To run it, we use the following command from the root of the project:

ruff --config ./backend/api/pyproject.toml --no-cache --fix --unsafe-fixes

Fixing common problems

Here, we discuss how we solve common linting problems in a consistent way.

Line too long - E501

A line too long typically arises with long strings, lists or a large function signature. All of them have in common that they are enclosed by some kind of delimiter.

To solve this, we put the first delimiter on the same line, each element on its own line and then the last delimiter on a new line as well. For example:

1. Before:

   def long_signature(arg_1: str, arg_2: int, arg_3: bool) -> str:

2. After:

   def long_signature(
       arg_1: str,
       arg_2: int,
       arg_3: bool,
   ) -> str:

Blind except - BLE001

Catching all exceptions arbitrarily might hide unexpected errors that are not foreseen during development. For example, suppose we validate a Pydantic model like this:

try:
  Model.model_validate(object)
except Exception:
  pass

If the object is invalid, this would raise a ValidationError. However, if anything else goes wrong, we would also catch this and ignore it. Making it harder to debug during execution.

Instead, we should always attempt to catch the specific exceptions we expect to encounter, so that unexpected ones are still raised.

try:
  Model.model_validate(object)
except ValidationError:
  pass

Caution

In the current version of the codebase we do bypass this rule often. Nevertheless, we should try to avoid it in the future, as well as fixing the current ones.

except Exception:  # noqa: BLE001