diff options
| -rw-r--r-- | CONTRIBUTING.md | 60 | ||||
| -rw-r--r-- | README.md | 2 |
2 files changed, 61 insertions, 1 deletions
diff --git a/CONTRIBUTING.md b/CONTRIBUTING.md new file mode 100644 index 0000000..8b15c02 --- /dev/null +++ b/CONTRIBUTING.md @@ -0,0 +1,60 @@ +# Contributing Guide + +Developers of this project highly appreciate your contribution, but +following the contributing guide makes collaboration much efficient. + +## Coding Style + +### Java + +1. Lower camel case for method names. Upper camel case for class names. +2. Annotate return values and parameters with @NotNull or @Nullable as +much as you can. +3. Document methods as much as you can. +4. Use IntelliJ Idea code style. Format your code before committing. +5. Always put `{}` after if or else. `if () xxx()` is not accepted for +the version control's sake. +6. Comments: `//` or `/*` or `/**`. +7. Do your best not to use third-party dependencies to keep the mod small. +Anything bundled in Minecraft, Fabric or Fabric API are fine. + +### C + +1. Use `func_name`, not `FuncName`, nor `funcName`. +2. Mark pointer arguments as `const` if it is not going to be changed in the +function. +3. Document functions as much as you can. +4. Use CLion code style. Format your code before committing. +5. Always put `{}` after if or else. `if () xxx()` is not accepted for +the version control's sake. +6. Comments: `/*` or `/**` only (not `//`). +7. During testing, make sure it works on both Unix and Windows. +8. Do not use platform-specific APIs unless wrapped in `ifdef`. +This includes anything POSIX, Linux-specific or Windows-specific. In other words, +Use as much as C standard API or library functions as possible. +9. Functions to be exported must start with `ac_` and annotated using `LIBAC_EXPORT`. +10. Headers in `libacron/include/` will be installed with distribution. Thus, only +put public headers here. + +## Commit Style + +1. Use Angular commit style. +2. If the WebSocket API or libacron API changes, put `API:CHANGE`, `API:ADD` or `API:DEL` +in the commit message body. +3. Try to explain the thing completely in the commit message. +4. Sign off the commit. + +## Testing + +Before sending patches, make sure you test your changes throughoutly. +Unit tests, although are currently absent, are better than manual tests. + +Keep threads safety in mind. Read library manuals carefully before using +them. + +## Sending Patches + +Before sending patches, make sure you tested it. + +Then, use `git-format-patch(1)` to generate an email and send it to +`yuuta@yuuta.moe`. The subject should include `[PATCH]`. @@ -175,7 +175,7 @@ Acron also provides a cli tool: [acronc(1)](client/acronc) for administrators. As a community project, I highly appreciate any help to this project. If you have any suggestions or patches, or if you find a bug or security issue, please send them to `yuuta@yuuta.moe`, and mention Acron in -the email subject. If you are sending a patch, please include `[PATCH]` in the subject as well. Thank you very much. +the email subject. If you are sending a patch, please read [Contributing Guide](CONTRIBUTING.md). ## License |