Skip to content

Latest commit

 

History

History
93 lines (61 loc) · 4.74 KB

CONTRIBUTING.md

File metadata and controls

93 lines (61 loc) · 4.74 KB

Thank you for considering to contribute to this project! 👍

How to contribute

This document shall help you to have a positive experience when contributing to this project. ☺️

General

  • In general the language for communication and documentation in this project is US English.
  • We enforce our Code of Conduct so that all contributors feel safe and valued. 🛡️
  • Don't be shy. Start to contribute today!

Options for contributing

  • If you have general questions or ideas, the discussions space may be the right place to start. You can open a new topic and we can try to answer your question or develop an idea with you.
  • If you are using the system and you found an error, please report an issue.
  • If you would like to contribute content to the source base (code, schematics, designs, documentation, ...):
    • It is a good idea to contact us before you start working. This way we can inform you of implicit requirements and current work in progress. Just to make sure your efforts will not be in vain.
    • If you are sure your proposition is an improvement (for example you want to fix a typo), go ahead, fork the repository and issue a pull request.

To get in touch with us you may contact a contributor directly (if they have contact information available) or create a topic in the discussions space.

Contributing Code

Before submitting to this repository, please:

Commit messages

Type a short, meaningful commit message that describes the change you made to the file.

Please consider the recommendation of the Git community for commit messages:

Begin the commit message with a single short (less than 50 character) line summarizing the change, followed by a blank line and then a more thorough description. The text up to the first blank line in a commit message is treated as the commit title, and that title is used throughout Git.

Pull requests

Use self-reviews to speed up the review process. This includes:

  • Review the content for technical accuracy.
  • If there are any failing checks in your PR, troubleshoot them until they're all passing.

Document your code

Please document your code in Doxygen compatible syntax.

C/C++ source code

Please format your changes using ClangFormat. A style configuration file is given: .clang-format

Although the standalone tool clang-format may be used, we recommend to integrate the formatting using a plugin for the editor of your choice.

Naming convention

For naming symbols in C or C++ we use the following rules to increase uniformity in our code:

  • Types: UpperCamelCase
  • Variables: lowerCamelCase
  • C preprocessor macros: MACRO_CASE
  • namespaces: snail_case
  • Template parameters: MACRO_CASE
  • Enumerators: MACRO_CASE
  • Prefix interface classes with a capital I
  • Do not use Hungarian notation.
  • If your file defines mainly one class, consider to name the file after the class.

This shall be a nonbinding guideline and does not need to be enforced neither technically nor in manual code reviews.

Doxygen configuration

If you change Doxyfile, please do a 'cleanup' by using the output of doxygen -x. For example

doxygen -x > Doxyfile.tmp && mv Doxyfile.tmp Doxyfile

PlatformIO configuration

If you change platformio.ini using PlatformIO Home, please note that comments may be deleted unsolicitedly by that tool. In general we want to preserve useful comments in the project configuration file.