Coding standards » History » Version 9
laforge, 02/21/2016 02:07 PM
1 | 9 | laforge | {{>toc}} |
---|---|---|---|
2 | |||
3 | 8 | laforge | h1. Osmocom coding standards |
4 | 1 | ||
5 | 8 | laforge | h1. Coding Style |
6 | |||
7 | In general, for the C-language projects we maintain in the Osmocom project, we follow the coding style |
||
8 | of the Linux kenrel. See https://www.kernel.org/doc/Documentation/CodingStyle for further information. |
||
9 | |||
10 | We will not debate about the coding style and whether some other style is better or worse. The important factor is not so much _which_ coding style is followed, as long as there is one well-defined coding style and that all developers adhere to it. |
||
11 | |||
12 | h2. Submitting Patches |
||
13 | |||
14 | For submitting patches, the best practises established by the Linux kernel development community should be followed, whenever applicable. See https://www.kernel.org/doc/Documentation/SubmittingPatches for further information. |
||
15 | |||
16 | The generally important topics are: |
||
17 | |||
18 | h3. Submit patches against a current source tree |
||
19 | |||
20 | At time of submission, our patches should be based on current @master@ branch of the respective project, or another (more current) feature branch of that repository. |
||
21 | |||
22 | h3. Use unified diff format |
||
23 | |||
24 | It's best to let git generate the patches, so you don't have to worry about that. |
||
25 | |||
26 | h3. Have meaningful descriptions in your patches |
||
27 | |||
28 | Every commit/patch should have an explanation in the commit message. |
||
29 | |||
30 | h3. Separate your changes |
||
31 | |||
32 | Separate each _logical change_ into a separate patch. |
||
33 | |||
34 | h3. Respond to review comments |
||
35 | |||
36 | h3. Include PATCH in the subject |
||
37 | |||
38 | |||
39 | h2. Rules of thumb |
||
40 | |||
41 | Some general rules of thumb: |
||
42 | * Consider using tools like @Lindent@ and @checkpatch.pl@ or @universalindentgui@ before submitting code |
||
43 | * Run @make@, @make check@ and @make distcheck@ on each of your commits to ensure the build |
||
44 | * Use @git send-email@ or @git imap-send@ to send your patches (otherwise your mail client may wrap around lines and corrupt your patch) |