forked from xen-project/xen
-
Notifications
You must be signed in to change notification settings - Fork 0
/
CODING_STYLE
122 lines (93 loc) · 3.12 KB
/
CODING_STYLE
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
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
Coding Style for the Xen Hypervisor
===================================
The Xen coding style described below is the coding style used by the
Xen hypervisor itself (xen/*) as well as various associated low-level
libraries (e.g. tools/libxc/*).
An exception is made for files which are imported from an external
source. In these cases the prevailing coding style of the upstream
source is generally used (commonly the Linux coding style).
Other parts of the code base may use other coding styles, sometimes
explicitly (e.g. tools/libxl/CODING_STYLE) but often implicitly (Linux
coding style is fairly common). In general you should copy the style
of the surrounding code. If you are unsure please ask.
Indentation
-----------
Indenting uses spaces, not tabs - in contrast to Linux. An indent
level consists of four spaces. Code within blocks is indented by one
extra indent level. The enclosing braces of a block are indented the
same as the code _outside_ the block. e.g.
void fun(void)
{
/* One level of indent. */
{
/* A second level of indent. */
}
}
White space
-----------
Space characters are used to spread out logical statements, such as in
the condition of an if or while. Spaces are placed between the
keyword and the brackets surrounding the condition, between the
brackets and the condition itself, and around binary operators (except
the structure access operators, '.' and '->'). e.g.
if ( (wibble & wombat) == 42 )
{
...
There should be no trailing white space at the end of lines (including
after the opening /* of a comment block).
Line Length
-----------
Lines should be less than 80 characters in length. Long lines should
be split at sensible places and the trailing portions indented.
User visible strings (e.g., printk() messages) should not be split so
they can searched for more easily.
Bracing
-------
Braces ('{' and '}') are usually placed on a line of their own, except
for the do/while loop. This is unlike the Linux coding style and
unlike K&R. do/while loops are an exception. e.g.:
if ( condition )
{
/* Do stuff. */
}
else
{
/* Other stuff. */
}
while ( condition )
{
/* Do stuff. */
}
do {
/* Do stuff. */
} while ( condition );
etc.
Braces should be omitted for blocks with a single statement. e.g.,
if ( condition )
single_statement();
Comments
--------
Only C style /* ... */ comments are to be used. C++ style // comments
should not be used. Multi-word comments should begin with a capital
letter. Comments containing a single sentence may end with a full
stop; comments containing several sentences must have a full stop
after each sentence.
Multi-line comment blocks should start and end with comment markers on
separate lines and each line should begin with a leading '*'.
/*
* Example, multi-line comment block.
*
* Note beginning and end markers on separate lines and leading '*'.
*/
Emacs local variables
---------------------
A comment block containing local variables for emacs is permitted at
the end of files. It should be:
/*
* Local variables:
* mode: C
* c-file-style: "BSD"
* c-basic-offset: 4
* indent-tabs-mode: nil
* End:
*/