added contributing.adoc
This commit is contained in:
parent
42ef57a3e7
commit
5cd44c7593
2 changed files with 67 additions and 0 deletions
66
CONTRIBUTING.adoc
Normal file
66
CONTRIBUTING.adoc
Normal file
|
@ -0,0 +1,66 @@
|
|||
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 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.
|
||||
|
||||
. Use clang-format
|
||||
+
|
||||
This should auto-format the rest: `find . -iname '*.c' -o '*.h' | xargs clang-format -i`.
|
||||
|
||||
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.
|
|
@ -50,6 +50,7 @@ You want to contribute? Great!
|
|||
|
||||
Future requests, bug reports and PRs are always welcome.
|
||||
Note that pull requests without a valid issue are ignored to decrease the amount of duplicate work.
|
||||
Also read file:CONTRIBUTING.adoc[CONTRIBUTING.adoc].
|
||||
|
||||
If anything is unclear, feel free to contact me.
|
||||
|
||||
|
|
Loading…
Reference in a new issue