guidelines for contributors

[CEXT-Dan]

There’s a lot of things I care about from a C++ perspective that might not align with best practices in Python. There are also conflicting ideas, such as PEP-8

I chose signatures that tries to match to the documentation

    Db.DbObject.createExtensionDictionary
    #vs
    Db.DbObject.create_extension_dictionary

https://help.autodesk.com/view/OARX/2025/ENU/?guid=OARX-RefGuide-AcDbObject__createExtensionDictionary

https://help.autodesk.com/view/OARX/2025/ENU/?guid=OARX-ManagedRefGuide-Autodesk_AutoCAD_DatabaseServices_DBObject_CreateExtensionDictionary

[CEXT-Dan]

Code of Conduct

• be nice

style guidelines

• no tabs, only spaces

Opening issues

• make a test case or be descriptive

Asking Questions

• open a discussion

Submitting Pull Requests

• no conflicts, tests pass

[gswifort]

we should also choose one docstring style (I prefer Google's style, but I don't know if I always use it correctly)

[rdesparbes]

I don't have a preference, but since the only docstrings in the project are in (almost) Google's style, we can stick with that!
I say almost because it is supposed to be Args and not Arguments. PyCharm and VSCode can parse both though.

My only opinion about that is to never specify the types in the docstrings, as they are harder to check and will end up diverging with the type hints. If we need to generate a documentation at some point, modern tools will extract the type annotations anyway.

So in VSCode's plugin autoDocstring, which I recommend, it would correspond to the docstring format called google-notypes.

[rdesparbes]

There are also conflicting ideas, such as PEP-8

I chose signatures that tries to match to the documentation

    Db.DbObject.createExtensionDictionary
    #vs
    Db.DbObject.create_extension_dictionary

Sticking to the conventions used in the OARX interface sounds natural. It is a common practice to disregard PEP 8 when it comes to wrappers (wx, gdal, Qt...)

These guildelines could be versioned in a CONTRIBUTING.md file at the root of the project, which is a well known standard.

[CEXT-Dan]

added CONTRIBUTING.md feel free to modify the styles for Python, or anything else

Just a note, it’s not my style to gate-keep or reject code based on style, but it is nice to have readable code.
If a linter is ever setup, it should be friendly.

I know all my samples would be rejected 😁

[gswifort]

It might be worth considering adding permissions for some people to create new branches and push changes to those branches. This would make it easier to collaborate and test changes before pushing them to main.

[CEXT-Dan]

Actually, I’ve been doing some initial investigation into this, possibly creating an organization.
I need to understand the pros, cons, and risks.

Also, I think it would be great of others could generate releases at some point too, have an autobuild machine or something…. Down the road