docs: Tweak location of qemu nbd extensions
[nbd.git] / CodingStyle
blobd17906c74af92fa2397c6dde38e7de455fea0d6a
1 NBD Coding style.
2 =================
4 The following expresses my opinion of what C code should look like. I'm
5 not as strict as the Kernel maintainers on this one (NBD isn't even
6 remotely as large anyway), but code that does not follow these rules
7 needs to be updated so that it does, which is useless time wasted for
8 me. Therefore, it's appreciated if you would follow these rules.
10 Thanks.
12 * Use a tab width of 8 characters. You may use tab or 8 spaces as you
13   please, it doesn't really matter to me.
14 * opening curly brackets occur on the same line as whatever they're
15   curly brackets for, _in all cases_. This includes function
16   definitions, if structures, loops, and so on; every code block appears
17   like so:
19 int foo(int bar) {
20         ...
23 * Variable declarations are separated from the rest of a function block
24   by a line of whitespace. It's okay to assign a value to a variable
25   when you're declaring it if you can do that on one line of code, but
26   it must still be in the block of declarations at the top with a
27   whiteline below.
28 * Variables are declared one on each line. So no
30         int foo, bar;
32   use
34         int foo;
35         int bar;
37   instead.
38 * Try to fit everything in 80 columns. This goes especially for comment
39   lines, but may be relaxed for function calls with 79 arguments, or so,
40   if that's not feasible.
41 * If your function block is more than three or so screenfulls, there's a
42   hint that you should break it up.
44 It is true that not all of the code currently follows these rules; but
45 that should not stop you from following them for new code, or from
46 cleaning up if you can (i.e., you have commit rights).