86 lines
2.7 KiB
Text
86 lines
2.7 KiB
Text
Contribution Guidelines
|
|
=======================
|
|
|
|
*Note*: contributing implies that your contributions get licensed under the terms of link:LICENSE[LICENSE] (MPL 2.0).
|
|
|
|
Opening issues
|
|
--------------
|
|
|
|
. Make sure you have a GitHub account.
|
|
. Include steps to reproduce, if it is a bug.
|
|
. Include information on what version you are using.
|
|
|
|
Submit changes
|
|
--------------
|
|
|
|
Commit messages should be both _clear_ and _descriptive_. If possible they should start with the _verb_ that describes the change.
|
|
Don't be shy to include additional information, like motivation, for that change below the initial line.
|
|
|
|
Other developers should be able to understand _why_ a change occurred, when looking at it at a later point in time.
|
|
|
|
Coding Style
|
|
~~~~~~~~~~~~
|
|
|
|
Make sure you adhere to the coding style, or your pull request might not get merged.
|
|
|
|
. Use tabs for indentation
|
|
+
|
|
While it makes no difference at all, this is clearly the superior choice, since only spacers will complain (as opposed to tabbers and spacers that use a different amount of spaces).
|
|
|
|
. Align using a single tab
|
|
+
|
|
I know this isn't what alignment is. I don't care though.
|
|
|
|
. Function calls don't take spaces before, nor inside the parenthesis
|
|
+
|
|
Use `function(param1, param2)` instead of `function ( param1, param2 )`.
|
|
|
|
. Use spaces between keywords and the parenthesis though
|
|
+
|
|
Use `if (condition)` instead of `if(condition)`.
|
|
|
|
. Curly brackets go on the same row
|
|
+
|
|
Saves space and I'm used to it.
|
|
|
|
. Function blocks start on a new row
|
|
+
|
|
This makes it easier with all the postfix operators, like `const`, which don't exist in C; I don't care.
|
|
|
|
. Use blocks even when just putting a single statement
|
|
+
|
|
This makes it easier to add more lines later, and we avoid two other discussions. This also doesn't break when you use a macro that expands to multiple statements.
|
|
|
|
. When things are related, use an `enum`.
|
|
+
|
|
Should be common sense. Seen too much code without it though.
|
|
|
|
. Comment `// FALLTHROUGH`, `// EMPTY` and `// NOTREACHED` where applicable
|
|
+
|
|
Explicit is better than implicit.
|
|
|
|
. Don't test against booleans or `NULL`.
|
|
+
|
|
Use the not operator instead.
|
|
|
|
. Test against numbers
|
|
+
|
|
Don't abuse that `0` is falsey.
|
|
|
|
. Put headers in this order
|
|
.. `#include "file.h"`
|
|
.. Standard lib headers
|
|
.. POSIX headers
|
|
.. Library headers
|
|
.. Own stuff
|
|
|
|
. Put blocks of headers in alphabetical order
|
|
+
|
|
If not possible comment which header requires the out-of-order one.
|
|
|
|
Why am I this pedantic?
|
|
~~~~~~~~~~~~~~~~~~~~~~~
|
|
|
|
I hate it when I look at code written by 10 people and I see 15 different coding styles, and got to wrap my head around every single one. I don't really care _what_ is used, but it needs to be consistent.
|
|
|
|
That said, if anything is unclear or I missed something feel free to open an issue.
|