# 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]`.