jalr/OpenRGB
1
0
Fork 0
Code Issues Pull requests Projects Releases Packages Wiki Activity Actions

Update contributing guide formatting, link to the contributing guide in the readme

Browse source
This commit is contained in:
Adam Honse 2022-03-13 13:11:43 -05:00
parent a07425026c
commit c8b34ccb0d
2 changed files with 35 additions and 34 deletions
Download patch file Download diff file Expand all files Collapse all files

68
CONTRIBUTING.md
View file

@ -6,11 +6,11 @@ The OpenRGB project welcomes contributions from the community. The project woul
To create a merge request, log into GitLab and fork the OpenRGB project. Push your changes to your fork and then use the Create Merge Request option. Before opening a merge request, please review the following best practices to help your merge request get merged without excessive delay.
* Please keep the scope of each merge request limited to one functional area. If you wish to add a new device controller, for instance, don't also do code cleanup in another controller as part of the same merge request.
* Explain what your merge request is changing, why you feel the change is necessary, and add any additional information you feel is needed to best understand your change in the merge request description.
* Mark your merge request as a draft (start title with "Draft:") until it has been tested and verified working.
* Follow the Style Guidelines below when making your code changes.
* Avoid using `git merge` when updating your fork. The OpenRGB project uses a linear git history, meaning all changes are rebased onto the tip of master. By using `git rebase` to update your fork, you will make it easier to accept merge requests.
* Please keep the scope of each merge request limited to one functional area. If you wish to add a new device controller, for instance, don't also do code cleanup in another controller as part of the same merge request.
* Explain what your merge request is changing, why you feel the change is necessary, and add any additional information you feel is needed to best understand your change in the merge request description.
* Mark your merge request as a draft (start title with "Draft:") until it has been tested and verified working.
* Follow the Style Guidelines below when making your code changes.
* Avoid using `git merge` when updating your fork. The OpenRGB project uses a linear git history, meaning all changes are rebased onto the tip of master. By using `git rebase` to update your fork, you will make it easier to accept merge requests.
## Style Guidelines
@ -18,38 +18,38 @@ OpenRGB is written in C++, uses the Qt framework for UI, and uses the QMake buil
### Functional Style
* Limit use of C++ std library data types
* For fixed-length containers, use C arrays
* For list constants, use const C arrays
* For fixed-length strings, use C char buffers ("C strings"), though using std::string is acceptable if the value will be placed in a std::string
* For basic types, prefer using the non-typedef'd basic types (char, short, int, etc) over typedef'd (uint8_t, uint16_t, uint32_t, etc)
* Unless defined in an OpenRGB API or the file is implementing an existing API using these types (such as i2c_smbus)
* For hard-coded values, use `#define`s over const variables unless you need a pointer to the value
* For variable-length containers, use std::vector
* For variable-length strings, use std::string
* `struct` should not include any functions, only variables
* `class` should only be used for objects containing functions
* Other std types may be used sparingly if necessary
* Only use Qt libraries, types, and functionality in user interface files
* Anything under the qt/ folder basically
* Do not use QDebug, use our LogManager instead. If you use QDebug during development, please remove it before submitting your merge request
* Use C-style indexed for loops when iterating through an array or vector
* Use C-style casts unless necessary
* Avoid the `auto` type. It makes code more difficult to read
* Do not use `printf` or `cout` for debug messages, use LogManager instead
* Don't define namespaces unless necessary
* Limit use of C++ std library data types
* For fixed-length containers, use C arrays
* For list constants, use const C arrays
* For fixed-length strings, use C char buffers ("C strings"), though using std::string is acceptable if the value will be placed in a std::string
* For basic types, prefer using the non-typedef'd basic types (char, short, int, etc) over typedef'd (uint8_t, uint16_t, uint32_t, etc)
* Unless defined in an OpenRGB API or the file is implementing an existing API using these types (such as i2c_smbus)
* For hard-coded values, use `#define`s over const variables unless you need a pointer to the value
* For variable-length containers, use std::vector
* For variable-length strings, use std::string
* `struct` should not include any functions, only variables
* `class` should only be used for objects containing functions
* Other std types may be used sparingly if necessary
* Only use Qt libraries, types, and functionality in user interface files
* Anything under the qt/ folder basically
* Do not use QDebug, use our LogManager instead. If you use QDebug during development, please remove it before submitting your merge request
* Use C-style indexed for loops when iterating through an array or vector
* Use C-style casts unless necessary
* Avoid the `auto` type. It makes code more difficult to read
* Do not use `printf` or `cout` for debug messages, use LogManager instead
* Don't define namespaces unless necessary
### Non-functional Style
* Set your editor's tab settings to insert spaces, using 4 spaces per tab stop
* Always put opening and closing braces `{`, `}` on their own lines
* Indent code inside the braces, do not indent the braces themselves
* Capitalize hexadecimal literals (`0xFF` not `0xff`) except in the udev rules file (which must be lowercase to work)
* No space between keyword and open parenthesis (`if(TRUE)` not `if (TRUE)`). There are some instances of this that haven't been cleaned up in the code.
* Generally, `snake_case` is used for variable names and `CamelCase` is used for function and class names
* Add a header comment to new files with the filename, description, original author, and date (this is missing on most Detect files)
* Line up `=` when doing a lot of assignments together
* Use this comment box style when adding comments:
* Set your editor's tab settings to insert spaces, using 4 spaces per tab stop
* Always put opening and closing braces `{`, `}` on their own lines
* Indent code inside the braces, do not indent the braces themselves
* Capitalize hexadecimal literals (`0xFF` not `0xff`) except in the udev rules file (which must be lowercase to work)
* No space between keyword and open parenthesis (`if(TRUE)` not `if (TRUE)`). There are some instances of this that haven't been cleaned up in the code.
* Generally, `snake_case` is used for variable names and `CamelCase` is used for function and class names
* Add a header comment to new files with the filename, description, original author, and date (this is missing on most Detect files)
* Line up `=` when doing a lot of assignments together
* Use this comment box style when adding comments:
```
/*--------------------------------*\

1
README.md
View file

@ -162,6 +162,7 @@ There have been two instances of hardware damage in OpenRGB's development and we
* Want to contribute support for a new device? Check out the [RGBController API](https://gitlab.com/CalcProgrammer1/OpenRGB/-/wikis/The-RGBController-API) page for documentation of how OpenRGB implements device control.
* Want to create a new OpenRGB SDK client implementation? Check out the [OpenRGB SDK Documentation](https://gitlab.com/CalcProgrammer1/OpenRGB/-/wikis/OpenRGB-SDK-Documentation) page for documentation of how the OpenRGB SDK network protocol functions.
* Please read the [Contributing Guidelines](https://gitlab.com/CalcProgrammer1/OpenRGB/-/blob/master/CONTRIBUTING.md) before starting work on your new changes.
## OpenRGB SDK