Basilisk and Sonar

[JeanLoupCaillet]

Hello,

I would like to propose some python rules in term of coding.
Indeed I'm using PyCharm IDE and a Sonar plugin (NB: VsCode also have the correct plugin) and I think it would be great for all of us if we respect the same coding rules.

https://docs.sonarqube.org/9.6/analyzing-source-code/languages/python/

What do you think ?
I'm open to the discussion :)

I provided a screenshot as example:

[patkenneally]

Hi @JeanLoupCaillet,

I agree. I also use PyCharm/CLion, with a combination of SonarLint, Cppcheck, and others. I have a config file for these tools which excludes certain rules. For example I selectively exclude the rule on regex matching for variables names given Basilisk chose camel case and established a format for writing math as a variable name back at the projects start.

So perhaps, a combination of a set of linting rules maintained in the repo, along with a linting tool configuration that can be run locally and as part of the CI pipelines would serve. My hope is that we do the same for module code, and Basilisk core architectural code.

[JeanLoupCaillet]

Hello @patkenneally,

I'm curious about the choice using CamelCase instead of snake_case because it's a python standard.
Is your listing rules set is available somewhere ?

Do you plan to put a coding rule on the Basilisk repository for all reporters ?
Let me know if I can be useful in anyway !

[joaogvcarneiro]

Hello @JeanLoupCaillet,

See Basilisk's Coding Guidelines. I hope it answers some of your questions.

[patkenneally]

Thanks for posting @joaogvcarneiro 🙏

@JeanLoupCaillet to recount the history :), when we first set out on Basilisk, we chose camel case for our C and C++ development. At the time we were much more focused on the core part of the system, with SWIG providing the python interface. Given that SWIG exposes the same camel case interface definitions, we decided to continue with camel case at the python layer, knowingly contrary to PEP8. Now, reflecting there are a number of different decisions we could make. A few, e.g. adjust the style for exposed interfaces, we could rewrite/overwrite the interface in the SWIG .i, we could choose snake case and just accept that the exposed interfaces from the underlying C/C++ compilation units. The primary consideration is about where we choose to draw the boundary. As always, I'm open to other ideas 😄

I hope that helps with context.