Skip to content

Latest commit

聽

History

History
63 lines (46 loc) 路 2.67 KB

CONTRIBUTING.md

File metadata and controls

63 lines (46 loc) 路 2.67 KB
Raw

Welcome to our contribution guidelines!

We're happy you want to contribute! Please try to adhere to the following rules to help us maintain a clean codebase and to make the merge-process as simple as possible!

Talk to us!

Before starting to work on any patches please talk to use before hand.
This helps us prevent situations where you may want to implement a feature that is already in the works.

We're always grateful for your contributions :) We just want to make sure your hard work doesn't go to waste!



Semantic Commits

Please always use semantic commit messages, so that we can keep track of the changes more easily!

Code Style

We follow a specific coding-style throughout the project:

  • Includes

    • Includes should be sorted by length where applicable
    • Project/Internal Headers always come first
    • System and Project Headers should be separated by a line break

  • Naming Convention

    • We use a "standard library-ish" naming convention

      As there is no such definitive convention, it is sometimes up to debate how to name things, but if you look through the source code you should get the gist of how to name things, it's mostly just snake_case, except for Template-Parameters, which should be in CamelCase.

  • Nesting

    • Function depth should be kept to a minimum
    • In cases where nesting increases the overview of the functions flow or is absolutely necessary, it may be used unless it is explicitly requested to not do so

  • File/Folder Structure

    • Implementation specific headers should be placed in the private directory
    • For each implementation header there should be a corresponding source file
    • For all public headers a ".inl" file should be preferred over inline definitions
    • Files should include their name and the operating-system they're designed for (only if applicable!) separated by a dot (.)

  • Clang-Tidy / Clang-Format

    • Before you commit your changes make sure that there are no clang-tidy warnings and format your code with our .clang-format config

  • Annotations

    • All functions exposed to the user should be annotated accordingly (only if applicable) [see annotations.hpp, for an example see webview.hpp]