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 waf command check_guidelines 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.
 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
#!/usr/bin/env python
# -*- coding: utf-8 -*-

# @copyright &copy; 2010 - 2021, Fraunhofer-Gesellschaft zur Foerderung der
#   angewandten Forschung e.V. All rights reserved.
#
# BSD 3-Clause License
# 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:
#
# &Prime;This product uses parts of foxBMS&reg;&Prime;
#
# &Prime;This product includes parts of foxBMS&reg;&Prime;
#
# &Prime;This product is derived from foxBMS&reg;&Prime;

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 black. The black configuration can be found in conf/fmt/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
 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
import os
import platform

def some_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

2.3.7. wscript Specific rules (PYTHON:007)

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

Listing 2.39 Format includes in wscript
 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
def build(bld):
    # ...
    # fmt: off
    # pylint: disable=line-too-long
    includes = [
        # ...
        os.path.join("..", "..", "os", bld.env.operating_system),
        os.path.join("..", "..", "os", bld.env.operating_system, "include"),
        os.path.join("..", "..", "os", bld.env.operating_system, "portable", "ccs", "arm_cortex-r5"),
        # ...
    ]
    # pylint: enable=line-too-long
    # fmt: on
    # ...

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

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