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
123
124
125
126
127
128
129
130
131
132
133
134
|
---------------------------------
The Mana Experiment Hacking Guide
---------------------------------
With multiple coders working on the same source files, there needs to be a
standard specifying how code is written down. Not doing so can cause quite some
annoyance for certain coders and easily creates more version conflicts than
necessary.
* Indentation:
Code is indented using 4 spaces, no tabs.
* Line length:
Should not exceed 79 characters.
One reason for this is to keep code readable. In such cases it would often be
better to spread the line over multiple lines or use some extra temporary
variables. Another reason is that some of us are using editors that default
to an 80 character wide screen, and often put two instances next to
eachother. 79 character wide lines leave just a spot for the cursor at the
end of the line.
* Control constructs like this:
Good:
if (condition)
{
}
else
{
}
for (init; condition; step)
{
}
while (condition)
{
}
/**
* Documentation about behaviour
* ...
*
* @param param1 the first argument
* @param param2 the second argument
*/
void function(param1, param2)
{
}
class TheClass : public TheSubclass
{
};
For if, for and while constructs, opening parenthesis may be placed on the
same line to save space.
In most cases these are bad:
if (condition)
statement;
if (condition) statement;
* Comments:
Single line C++ style comments are indented the same as the previous line.
Good:
// comment
Multiple line C style comments are initially indented like previous line
except every new line of the comment begins with a asterisk ('*') which lines
up with the initial asterisk of the comment opening (1 space indent). The
comment is closed also with the asterisk lining up. Comment text is only
placed on a line starting with a asterisk.
Good:
/*
* Some comment
* additional comment material
*/
Bad:
/* text
comment
*/
Note that for documenting functions, methods and other things that can use
documentation, you should use Doxygen style as in the function example above.
For details see the manual at http://www.doxygen.org/.
* Whitespace examples:
Good:
x = ((5 + 4) * 3) / 1.5;
afunction(12, 3, (1 + 1));
Bad:
x = ( ( 5 + 4 ) * 3 ) / 1.5;
afunction(12,3,(1+1));
* Method, class, member and constant naming is based on the
generally accepted way Java code is written.
Class: CapitalizedWords
Method: camelCase
Member: mCamelCase
Constant/enum: UPPERCASE_UNDERSCORES
To denote global variables and functions the lowercase_underscores style may
be used. Hungarian style should be avoided.
* Whenever you add a new source file somewhere in ./src do not forget to add
them in ./src/Makefile.am as well!
* ChangeLog file format:
YYYY-MM-DD[space][space]Firstname[space]Lastname[space][space]<email@address>
[newline]
[tab]*[space]filename:[space]Comment
[newline]
The last character on each line is at max at column 79.
Example:
1234-12-24 Some Body <mymail@mailserver.tld>
* some/file: My comment.
* some/file, anotherfile: This is a pretty long comment and needs a
line break, to avoid characters at colums > 79.
|
