2020-04-19 06:58:11 -07:00
|
|
|
## Contributing to river
|
|
|
|
|
2024-03-22 08:49:28 -07:00
|
|
|
Contributing is as simple as opening a pull request on
|
|
|
|
[codeberg](https://codeberg.org/river/river).
|
|
|
|
You'll likely have more success with your contribution if you visit
|
|
|
|
[#river](https://web.libera.chat/?channels=#river) on irc.libera.chat to discuss
|
|
|
|
your plans first.
|
2020-04-19 06:58:11 -07:00
|
|
|
|
|
|
|
## Commit messages
|
|
|
|
|
2020-06-04 15:56:50 -07:00
|
|
|
Please take the time to write a good commit message, having a clean git
|
|
|
|
history makes maintaining and contributing to river easier. Commit messages
|
|
|
|
should start with a prefix indicating what part of river is affected by the
|
|
|
|
change, followed by a brief summary.
|
|
|
|
|
|
|
|
For example:
|
|
|
|
|
|
|
|
```
|
|
|
|
build: scan river-status protocol
|
|
|
|
```
|
|
|
|
|
|
|
|
or
|
|
|
|
|
|
|
|
```
|
|
|
|
river-status: send view_tags on view map/unmap
|
|
|
|
```
|
2020-04-19 06:58:11 -07:00
|
|
|
|
|
|
|
In addition to the summary, feel free to add any other details you want preceded
|
|
|
|
by a blank line. A good rule of thumb is that anything you would write in a pull
|
2024-03-22 08:49:28 -07:00
|
|
|
request description on codeberg has a place in the commit message as well.
|
2020-04-19 06:58:11 -07:00
|
|
|
|
2020-06-04 15:56:50 -07:00
|
|
|
For further details regarding commit style and git history see
|
|
|
|
[weston's contributing guidelines](https://gitlab.freedesktop.org/wayland/weston/-/blob/master/CONTRIBUTING.md#formatting-and-separating-commits).
|
2020-04-19 06:58:11 -07:00
|
|
|
|
|
|
|
## Coding style
|
|
|
|
|
|
|
|
Please follow the
|
2020-04-19 07:03:42 -07:00
|
|
|
[Zig Style Guide](https://ziglang.org/documentation/master/#Style-Guide)
|
2021-01-02 03:07:21 -08:00
|
|
|
and run `zig fmt` before every commit. With regards to line length, keep it
|
|
|
|
under 100 columns in general but prioritize readability over adhering to a
|
|
|
|
strict limit. Note that inserting a trailing comma after the last parameter in
|
|
|
|
function calls, struct declarations, etc. will cause `zig fmt` to wrap those
|
|
|
|
lines. I highly recommend configuring your editor to run `zig fmt` on write.
|
2020-04-19 06:58:11 -07:00
|
|
|
|
2022-03-02 06:34:51 -08:00
|
|
|
The single additional style rule is to avoid writing `if` statements and
|
|
|
|
similar across multiple lines without braces:
|
|
|
|
|
|
|
|
```zig
|
|
|
|
test {
|
|
|
|
// avoid this
|
|
|
|
if (foo)
|
|
|
|
bar();
|
|
|
|
|
|
|
|
// prefer this
|
|
|
|
if (foo) bar();
|
|
|
|
|
|
|
|
// or this
|
|
|
|
if (foo) {
|
|
|
|
bar();
|
|
|
|
}
|
|
|
|
}
|
|
|
|
```
|
|
|
|
|
2020-04-19 06:58:11 -07:00
|
|
|
On a higher level, prioritize simplicity of code over nearly everything else.
|
|
|
|
Performance is only a valid reason for code complexity if there are profiling
|
|
|
|
results to back it up which demonstrate a significant benefit.
|