kiwmi/CONTRIBUTING.adoc

Contribution Guidelines

Note: contributing implies that your contributions get licensed under the terms of LICENSE (MPL 2.0).

Opening issues

1. Make sure you have a GitHub account.

2. Include steps to reproduce, if it is a bug.

3. 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.

1. 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.

2. When things are related, use an enum.

   Should be common sense. Seen too much code without it though.

3. Comment // FALLTHROUGH, // EMPTY and // NOTREACHED where applicable

   Explicit is better than implicit.

4. Don’t test against booleans or NULL.

   Use the not operator instead.

5. Test against numbers

   Don’t abuse that 0 is falsey.

6. Put headers in this order

   1. #include "file.h"

   2. Standard lib headers

   3. POSIX headers

   4. Library headers

   5. Own stuff

7. Put blocks of headers in alphabetical order

   If not possible comment which header requires the out-of-order one.

8. 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.