CONTRIBUTING.md (3112B)
1 # CONTRIBUTING 2 3 ## Commit messages 4 5 Commit messages should start with a prefix indicating which part of the 6 project is affected by your change, if this a general code patch you may not 7 add it, followed by a one sentence summary, first word is capitalized. First 8 line is 50 columns long max. 9 10 Example: 11 12 seat: Add pointer events 13 14 Update to zig 1.0.0 15 16 You can add everything you feel need to be mentioned in the body of the 17 commit message, wrap lines at 72 columns. 18 19 A great guide to follow [here](https://gitlab.freedesktop.org/wayland/weston/-/blob/master/CONTRIBUTING.md#formatting-and-separating-commits). 20 21 ## Patches 22 23 For patches send a **plain text** mail to the [public inbox](https://lists.sr.ht/~novakane/public-inbox) 24 [~novakane/public-inbox@lists.sr.ht](mailto:~novakane/public-inbox@lists.sr.ht) 25 with project prefix set to `zig-fcft`: 26 27 The prefix will looks like this `[PATCH zig-fcft] <commit-message>` 28 29 You can configure your Git repo like so: 30 31 ```bash 32 git config sendemail.to "~novakane/public-inbox@lists.sr.ht" 33 git config format.subjectPrefix "PATCH zig-fcft" 34 ``` 35 36 Some useful resources if you're not used to send patches by email: 37 38 - Using [git send-email](https://git-send-email.io). 39 - [plain text email](https://useplaintext.email/), if you need a better email 40 client and learn how to format your email. 41 - Learn [git rebase](https://git-rebase.io/). 42 - [pyonji](https://git.sr.ht/~emersion/pyonji) an easy-to-use cli tool to send e-mail patches. 43 44 `git.sr.ht` also provides a [web UI](https://man.sr.ht/git.sr.ht/#sending-patches-upstream) if you prefer. 45 46 ## Issues 47 48 Questions or discussions works the same way than patches, precise the project 49 name in the subject, you just don't need to add `PATCH` before the project name, 50 e.g. `[zig-fcft] how do I do this?` 51 52 ## Coding style 53 54 Follow [zig style guide](https://ziglang.org/documentation/0.8.0/#Style-Guide) 55 no other option for _zig_ which is kinda great. 56 57 Some things are not enforced by `zig fmt`, I do have an opinion on some of 58 these things though: 59 60 - Use snake_case for function name, I know this is a pretty big difference 61 from the official style guide but it makes code so much more readable. 62 - Wrap lines at 100 columns unless it helps readability. 63 - Use the struct name instead of Self. 64 65 ```zig 66 // Foo.zig 67 const Foo = @This(); 68 69 // Do this 70 pub fn init(foo: *Foo) void {} 71 // instead of this 72 pub fn init(self: *Foo) void {} 73 ``` 74 75 - For small `if` condition, use: 76 77 ```zig 78 if (false) return; 79 80 // or 81 82 if (false) { 83 return; 84 } 85 86 // Do not use this: 87 88 if (false) 89 return; 90 91 ``` 92 93 - Format using `zig fmt` before every commit, some tips to use it: 94 95 ```zig 96 pub example_function( 97 args1: type, 98 args2: type, 99 args3: type, 100 args4: type, // <- Use a comma here so zig fmt respect it 101 ) void {} 102 ``` 103 104 ```zig 105 if (cond1 == 1 and // <- Line break after and/or 106 cond2 == 2 and 107 cond3 == 3 and cond4 == 4 or // <- Works like this too 108 cond5 == 5) {} 109 ``` 110 111