2.3. Python Coding Guidelines

These coding guidelines MUST be applied to all Python files.

The source files MUST be successfully checked by running the pre-commit check before files can be merged into the master branch of the repository.

The following rules generally apply and follow the naming schema PYTHON:<ongoing-number>.

2.3.1. Filenames (PYTHON:001)

The following rules apply for filenames of Python scripts.

Python Script Filenames

• The general file naming rules MUST be applied (see Section 2.1.1), except that dashes (-) SHOULD not be used.

• Python scripts MUST use .py as file extension, except for Waf build scripts which use wscript as file name.

For example the valid file names for batch scripts are

• hello.py

• my-script.py (not recommended, as the script is not importable)

• my_script.py (recommended, the script is importable)

2.3.2. Header (PYTHON:002)

Python file header

Python source and header files MUST start with the following header:

Listing 2.37 File header for .py files.

#!/usr/bin/env python3
#
# Copyright (c) 2010 - 2024, Fraunhofer-Gesellschaft zur Foerderung der angewandten Forschung e.V.
# All rights reserved.
#
# SPDX-License-Identifier: BSD-3-Clause
#
# Redistribution and use in source and binary forms, with or without
# modification, are permitted provided that the following conditions are met:
#
# 1. Redistributions of source code must retain the above copyright notice, this
#    list of conditions and the following disclaimer.
#
# 2. Redistributions in binary form must reproduce the above copyright notice,
#    this list of conditions and the following disclaimer in the documentation
#    and/or other materials provided with the distribution.
#
# 3. Neither the name of the copyright holder nor the names of its
#    contributors may be used to endorse or promote products derived from
#    this software without specific prior written permission.
#
# THIS SOFTWARE IS PROVIDED BY THE COPYRIGHT HOLDERS AND CONTRIBUTORS "AS IS"
# AND ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE
# IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE ARE
# DISCLAIMED. IN NO EVENT SHALL THE COPYRIGHT HOLDER OR CONTRIBUTORS BE LIABLE
# FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL
# DAMAGES (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR
# SERVICES; LOSS OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION) HOWEVER
# CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT LIABILITY,
# OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY OUT OF THE USE
# OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGE.
#
# We kindly request you to use one or more of the following phrases to refer to
# foxBMS in your hardware, software, documentation or advertising materials:
#
# - "This product uses parts of foxBMS®"
# - "This product includes parts of foxBMS®"
# - "This product is derived from foxBMS®"

2.3.3. Syntax (PYTHON:003)

The following rules apply for syntax of Python scripts

Python syntax rules

• Python 2 only syntax MUST NOT be used.

• Python 3 only syntax MAY be used.

• Code MUST work in Python 3.6 or greater.

2.3.4. Formatting (PYTHON:004)

Uniform formatting makes code easier to read to all developers.

Python formatting rules

Python source files are checked for correct formatting by ruff. The ruff configuration can be found in pyproject.toml.

2.3.5. Static program analysis (PYTHON:005)

Static program Analysis helps to detected code smells and errors in an early stage of development.

Python static program analysis rules

Python sources files are statically checked by pylint. The pylint configuration can be found in conf/spa/.pylintrc.

2.3.6. No platform specific code (PYTHON:006)

No platform specific code

Python scripts MUST use platform independent code where ever possible. If platform specific is required, it MUST be guarded.

Example Listing 2.38 shows how to write platform acceptable platform specific code.

Listing 2.38 Handling of platform specific code

import os
import platform


def some_function():
    """Just a dummy function"""
    if platform.uname().system.lower().startswith("win"):
        print("Some Windows code")
    else:
        print("Feature only support on windows")

    path = "some/path"  # bad - works on all platforms, but no good style
    path = "some\\path"  # bad - works only on Windows
    path = os.path.join("some", "path")  # good - works on every platform
    print(path)

2.3.7. wscript Specific rules (PYTHON:007)

includes and source or might be less readable if they are split over multiple lines (as ruff would format it like this on default). Therefore includes and source might be written as follows, if it increases readability:

Listing 2.39 Format includes in wscript

import os


def build(bld):
    """builds something..."""
    # fmt: off
    # pylint: disable=line-too-long
    includes = [
        # ...
        os.path.join("..", "..", "os", "freertos"),
        os.path.join("..", "..", "os", "freertos", "include"),
        os.path.join("..", "..", "os", "freertos", "portable", "ccs", "arm_cortex-r5"),
        # ...
    ]
    # pylint: enable=line-too-long
    # fmt: on

• # fmt: off disables formatting starting from that line and # pylint: disable=line-too-long disables the pylint error message starting from that line.

• # fmt: on re-activates on formatting starting from that line and # pylint: enable=line-too-long re-activates the pylint error message starting from that line.