Contributing guidelines

When submitting pull requests

Explain your thinking in why a change or addition is needed.
- Is it a requested change or feature?
- If not, open a feature request to get feedback before making a pull request.
Split up multiple unrelated changes in multiple pull requests.
If it's a fix for a unreported bug, make a bug report and link the pull request.
Purely cosmetic changes won't be accepted without a very good explanation of its value.
Submissions where the majority of the code is AI generated must be marked with [AI generated].
"Vibe coded" PR's where it seems like the author doesn't understand the generated code will be dismissed.

Indent type: Tabs
Tab size: 4
Alternative operators and, or and not.
Opening curly braces { at the end of the same line as the statement/condition.

Don't force a programming style. Use object oriented, functional, data oriented, etc., where it's suitable.
Use RAII.
Make use of the standard algorithms library, watch C++ Seasoning and 105 STL Algorithms for inspiration.
Use the included fmt library for string formatting, see issue #535 for more info and examples.
Do not add includes if the same functionality can be achieved using the already included libraries.
Use descriptive names for variables.
Use comments if not very obvious what your code is doing.
Add comments as labels for what's currently happening in bigger sections of code for better readability.
Avoid writing to disk.
If using the logger functions, be sensible, only call it if something of importance has changed.
Benchmark your code and look for alternatives if they cause a noticeable negative impact.

For questions open a new discussion thread or send a mail to jakob@qvantnet.com

For proposing changes to this document create a new issue.