Naming policy

[Quentin_Plsn]

Hello everyone,

I'm just starting out with FreeCAD programming and I would like some clarification regarding the naming conventions in Python. I have already looked at the related topics on the forum but it is still not clear to me. In most workbenches, there is a mix of mixedCase and CamelCase for functions and variables, instead of snake_case, which is also used, but more rarely for functions. I don't think these are mistakes because this is even the case in the Wiki example (below).

Code: Select all

class MyWorkbench (Workbench):

    MenuText = "My Workbench"
    ToolTip = "A description of my workbench"
    Icon = """paste here the contents of a 16x16 xpm icon"""

    def Initialize(self):
    
    [...]
       
Gui.addWorkbench(MyWorkbench())

From the information* at my disposal, I notice: MyWorkbench is a class; Workbench is a class; MenuText, ToolTip and Icon instead of menu_text, tool_tip and icon (variables); Initalize instead of initialize (function); addWorkbench instead of add_workbench (function).

*Extract from PEP8 :

"Function names should be lowercase, with words separated by underscores as necessary to improve readability.

Variable names follow the same convention as function names.

mixedCase is allowed only in contexts where that’s already the prevailing style (e.g. threading.py), to retain backwards compatibility."

*Extract from Draft "naming policy" :

• Follow PEP 8.
• snake_case_names.py for modules.
• variable_names_without_capitals for variables.
• CamelCaseClass for classes.
• CONSTANTS_USE_CAPITALS for constants.
• functions_without_capitals() for functions and class methods.
• Functions expected to return a value should indicate what is expected, so is_mesh_valid is a good name, but check_mesh is not a good name.
• Class names, method names, and variables that are auxiliary, and not meant to be part of the public interface should start with an underscore like _MyInternalClass or _my_small_variable.

[Quentin_Plsn]

Ok, I just realized that there is actually no one way to name code in FreeCAD. I think I will follow the example of FCGear, which follows the PEP8 recommendations.

[chennes]

Just keep in mind that if you are developing a Workbench, as in the Wiki example, you don't have a choice about those variable names: even FCGear has to use the expected capitalization there...

Code: Select all

class GearWorkbench(Workbench):
    """glider workbench"""
    MenuText = "Gear"
    ToolTip = "Gear Workbench"
    Icon = os.path.join(__dirname__,  'icons', 'gearworkbench.svg')

[onekk]

And PEP8 is telling that with existing code you have to follow the rules in the code. Probably FC that is "more than 20 years old' use a different convention.

Draft code was almost totally rewritten to make it follow sone rules, but if you read the sources you will see that many methods have two form one is the "new form" other is the old "deprecated" form keep for compatibility.

If the WB is coded by you have to choose wathever method you want, as example Curves WB use the new suggested way of source code set up that use a freecad subdir were the code reside.

Regards.

Carlo D.

[adrianinsaval]

a lot of the time python code in freecad is influenced by it's C++ counterpart, where I believe camelCase is more widely used, the python code just mimics this and once a big chunk of it is already using that, it can be better to just use that for the rest.