-
Notifications
You must be signed in to change notification settings - Fork 4
Description
🐞 Problem
The current state of the Python modules that compose the Python API for STK is non-compliant with the PyAnsys guidelines.
💡 Solution
All code style changes need to be applied during the generation of the Python API. However, we can apply some of those in this repository to have an idea on how the auto-generated f This sub-pacakge is missing the __init__.py file.iles should look like.
The following tasks need to be solved to achieve a PyAnsys code style:
-
Use the PyAnsys namespace
ansys.stk.core#12
Only the root base modules are using an absolute namespace, the rest are defined using relative imports. -
Use snake case for methods and Pascal case for classes #13
The naming conventions used in PyAnsys are snake case for functions and methods and Pascal case for classes. This applies in the Python ecosystem too. -
Naming enums into macros #14
The naming convention used for enumerations is macros-like. This means that enumerations objects should be completely written with capital letters. As an example, consider the following conversionAgEVePropagatorType.ePropagatorTwoBodyconverts toPROPAGATOR_TYPE.TWO_BODY. -
Remove prefixes in classes and enumerations #15
Prefixes such as IAg, IAgVA (among others) are no longer required. Some objects may be affected when removing the prefix, leading to non valid Python syntax. For example, removing the prefixes in the enumeration and applying naming conventionsAgEVePropagatorType.ePropagator11Paramleads toPROPAGATOR_TYPE.11_PARAM, which is not allowed in Python syntax, since the enumeration item starts with a number. Particular cases need to be applied and documented. -
Use double quotes for docstrings and strings #16
Three double quotes should be used when declaring a docstring. In addition, any string should be declared using double quotes instead of single quotes. -
Summary docstrings should end with a period and be defined in one line #17
The first line of a docstring is used as a summary of the method and must end with a period. -
Stop using
*for imports #18
Required imports should be explicit. Nowadays, the usage of*is considered a bad practice. This type of import seems to be common across the current modules. -
Add missing
__init__.pyfile inplugins/#19
This sub-pacakge is missing the__init__.pyfile. -
Fixing spelling errors #20
Some spelling errors need to be fixed. -
Missing docstring in public module #69
Library modules need to contain a docstring. -
Missing docstring in public package #70
Library packages__init__.pyfiles need to contain a docstring.