1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
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]`.
|
