Introduce linter to enforce consistent coding conventions

[moritzsommer]

Current Situation

Currently, there are no consistent coding conventions for contributions to this codebase. As the project is open source, inconsistencies and with that reduced code readability may be introduced by people following different coding guidelines.

Examples for inconsistencies are:

• Blank lines after docstrings:

  basyx-python-sdk/sdk/basyx/aas/model/submodel.py

  Lines 573 to 576 in a6a904a

  	:ivar embedded_data_specifications: List of Embedded data specification.
  	"""
  	def __init__(self,

  basyx-python-sdk/sdk/basyx/aas/model/submodel.py

  Lines 622 to 624 in a6a904a

  	:ivar embedded_data_specifications: List of Embedded data specification.
  	"""
  	def __init__(self,

  I am not sure how to handle this, as it is a well-discussed topic.
• Missing second blank line:

  basyx-python-sdk/etc/scripts/check_python_versions_supported.py

  Lines 49 to 51 in a6a904a

  	f"and max_version [{max_version}] is released.")
  	if __name__ == "__main__":

• Whitespaces (around operators):

  basyx-python-sdk/sdk/basyx/aas/model/datatypes.py

  Line 587 in a6a904a

  microseconds=int(float(match[10])*1e6) if match[10] else 0)

• Unused imports:

  basyx-python-sdk/sdk/basyx/aas/backend/local_file.py

  Line 14 in a6a904a

  from typing import List, Iterator, Iterable, Union

• Unsorted import blocks:

  basyx-python-sdk/sdk/basyx/aas/model/datatypes.py

  Lines 26 to 32 in a6a904a

  	import base64
  	import datetime
  	import decimal
  	import re
  	from typing import Type, Union, Dict, Optional
  	import dateutil.relativedelta

• Line is too long:

  basyx-python-sdk/etc/scripts/check_python_versions_supported.py

  Line 17 in a6a904a

  eol_versions = {entry["cycle"]: {"eol": entry["eol"], "releaseDate": entry["releaseDate"]} for entry in eol_data}

• ...

Proposed Change

To avoid inconsistencies and style violations in both existing and future code, I suggest adding a linter. This linter could be used for pre-commit checks, as well as for CI checks. Since we already use mypy for type checking, adding a linter would be the next logical step. If we wanted to take it a step further, we could also check for code smells.

I have researched the following linter options:

• Ruff: Probably the newest and most efficient linter out there, with many out-of-the-box tools
• Pylint: Very customisable, best if we want to enforce project-specific guidelines
• Flake8: Quite lightweight, easy to use, many plugins
• Black: Classic code formatter