kitchen/kiwmi
2
0
Fork 0
Code Issues Pull requests Projects Releases Packages Wiki Activity

Get away from adoc

Browse source
This commit is contained in:
buffet 2019-10-16 19:13:20 +02:00
parent 258f4fab9a
commit 16653242e8
3 changed files with 21 additions and 68 deletions
Show stats Download patch file Download diff file Expand all files Collapse all files

66
CONTRIBUTING.adoc
View file

@ -1,66 +0,0 @@
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.

19
CONTRIBUTING.txt Normal file
View file

@ -0,0 +1,19 @@
Contribution Guidelines
=======================
Note: contributing implies that your contributions get licensed under the terms of 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.

4
README.txt
View file

@ -17,7 +17,7 @@ In the future there might be a base to base your stuff on, but at the moment thi
Dependencies
------------
- https://github.com/swaywm/wlroots[wlroots]
- wlroots (https://github.com/swaywm/wlroots)
- meson (build)
- ninja (build)
- git (build, optional, to fetch the version)
@ -45,7 +45,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 link:CONTRIBUTING.adoc[CONTRIBUTING.adoc].
Also read CONTRIBUTING.adoc.
If anything is unclear, feel free to contact me.