|
| 1 | +Contributions are much appreciated! |
| 2 | + |
| 3 | +## Table of contents |
| 4 | + |
| 5 | ++ [Reporting bugs](#reporting-bugs) |
| 6 | ++ [Proposing features or improvements](#proposing-features-or-improvements) |
| 7 | ++ [Contributing pull requests](#contributing-pull-requests) |
| 8 | ++ [Coding guidelines](#coding-guidelines) |
| 9 | + |
| 10 | +## Reporting bugs |
| 11 | + |
| 12 | ++ Open one issue per bug |
| 13 | ++ Specify the distro you're using, in particular if it's a build system bug |
| 14 | ++ Provide steps to reproduce the bug |
| 15 | ++ Provide the expected behavior if it's unclear |
| 16 | + |
| 17 | +## Proposing features or improvements |
| 18 | + |
| 19 | +Please do! Developers tend to develop blind spots after a while, new ideas are welcome. Even if the proposed feature was on the roadmap already, it doesn't hurt to open an issue for it, plus it can be expanded on there. |
| 20 | + |
| 21 | +## Contributing pull requests |
| 22 | + |
| 23 | ++ Make sure there is a corresponding issue in the tracker, create one if needed |
| 24 | ++ If you need help, ask |
| 25 | + + Even if you don't, the project owner will pop up after a while with unsolicited advice |
| 26 | ++ Read the **coding guidelines** in the [next section](#coding-guidelines) of this page |
| 27 | ++ Consult this project's wiki, there are rare cases where it may help |
| 28 | ++ Open your PR to get feedback |
| 29 | + + feel free to open it early as a work-in-progress |
| 30 | ++ It'll get merged once approved! |
| 31 | + + Intermediate commits may be squashed into one when merging if they're not directly related to the purpose of the PR: you can rebase your branch yourself if you wish to clean its commits yourself |
| 32 | + |
| 33 | +## Coding guidelines |
| 34 | + |
| 35 | +Readability is considered important; try to keep the coding style uniform. Here are the guidelines in use: |
| 36 | + |
| 37 | ++ indent using four spaces |
| 38 | ++ use snake_case at all times |
| 39 | ++ curly braces on the same line in all cases: `if (foo) {`, etc... |
| 40 | + + put a space before curly braces |
| 41 | ++ curly braces for single line `if`s `for`s and `while`s |
| 42 | ++ a space between keywords and their parentheses: `if ()`, `for ()` |
| 43 | + + except when they behave like functions: `sizeof()`, `offsetof()` |
| 44 | ++ spaces around arithmetic operators: `a + b % c == 0` |
| 45 | ++ pointers' `*` are put close to the type: `type_t* ptr = NULL`; |
| 46 | ++ a blank line before and after control structures: |
| 47 | + ```c |
| 48 | + int blah = bar(); |
| 49 | + |
| 50 | + if (blah) { |
| 51 | + ...; |
| 52 | + } |
| 53 | + |
| 54 | + ...; |
| 55 | + ``` |
| 56 | + + except when the previous line is also a control structure, e.g. nested loops, an `if` within a loop, etc... |
| 57 | ++ no extra blank lines otherwise, or trailing whitespace |
| 58 | ++ use sized `ints` within the kernel: `uint32_t`, `uint8_t` etc... or their signed versions if needed |
| 59 | ++ prefer lines that fit within 80-90 columns if possible |
| 60 | +
|
| 61 | +Example taken from [kernel/src/misc/wm/wm.c](https://github.com/29jm/SnowflakeOS/blob/022fc799b6841aa1365b28ac53832bb2f1cefc2f/kernel/src/misc/wm/wm.c#L406-L419): |
| 62 | +```c |
| 63 | +/* Return the window iterator corresponding to the given id, NULL if none match. |
| 64 | + */ |
| 65 | +list_t* wm_get_window(uint32_t id) { |
| 66 | + list_t* iter; |
| 67 | + wm_window_t* win; |
| 68 | +
|
| 69 | + list_for_each(iter, win, &windows) { // counts as a `for` loop |
| 70 | + if (win->id == id) { |
| 71 | + return iter; |
| 72 | + } |
| 73 | + } |
| 74 | +
|
| 75 | + return NULL; |
| 76 | +} |
| 77 | +``` |
0 commit comments