kitchen/kiwmi
2
0
Fork 0
Code Issues Pull requests Projects Releases Packages Wiki Activity
kiwmi/CONTRIBUTING.adoc
buffet 59bda74489 Added contributing guidelines
2018-09-28 17:46:23 +02:00

2.7 KiB
Raw Blame History

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

  2. Align using a single tab

    I know this isn’t what alignment is. I don’t care though.

  3. Function calls don’t take spaces before, nor inside the parenthesis

    Use function(param1, param2) instead of function ( param1, param2 ).

  4. Use spaces between keywords and the parenthesis though

    Use if (condition) instead of if(condition).

  5. Curly brackets go on the same row

    Saves space and I’m used to it.

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

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

  8. When things are related, use an enum.

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

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

    Explicit is better than implicit.

  10. Don’t test against booleans or NULL.

    Use the not operator instead.

  11. Test against numbers

    Don’t abuse that 0 is falsey.

  12. Put headers in this order

    1. #include "file.h"

    2. Standard lib headers

    3. POSIX headers

    4. Library headers

    5. Own stuff

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