blob: 47ddf410042ea92eb25f928e8fa1b649613c7d86 (
plain)
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
135
136
137
138
139
140
141
142
143
144
145
146
147
|
Since I tend to be one of the more pedantic people on coding style I'll provide
a bit of a reference here. Please take a few minutes to read this as it will
save us both time when processing patches.
================================================================================
Indentation
================================================================================
The older files in JuK are indented using Qt-style. The first level was 4
spaces, the second one tab, the third one tab followed by 4 spaces. I'm not
particularly fond of this style anymore, but it used to be the Emacs default
when using the KDE Emacs scripts.
static void foo()
{
if(bar()) // <-- 4 spaces
baz() // <-- 1 tab
}
Newer files simply use 4 spaces at all levels. In most cases the style of the
file currently being worked in should be followed. So:
static void foo()
{
if(bar()) // <-- 4 spaces
baz() // <-- 8 spaces
}
================================================================================
Braces
================================================================================
Braces opening classes, structs, namespaces and functions should be on their own
line. Braces opening conditionals should be on the same line with one notable
exception: if the conditional is split up onto several lines then the opening
brace should be on its own line. i.e.
class Foo
{
// stuff
};
if(foo == bar) {
// stuff
}
while(foo == bar &&
baz == quux &&
flop == pop)
{
// stuff
}
static void foo()
{
// stuff
}
Other exceptions include inline functions that are just returning or setting a
value. However multiple statements should not ever be combined onto one line:
class Foo
{
public:
String value() const { return m_value; }
};
Also conditionals / loops that only contiain one line in their body (but where
the conditional statement fits onto one line) should omit braces:
if(foo == bar)
baz();
But:
if(baz == quux &&
ralf == spot)
{
bar();
}
================================================================================
Spaces
================================================================================
Spaces should not be used between the conditional / loop type and the
conditional statement. They should also not be used after tqparenthesis. However
the should be to mark of mathematical or comparative operators.
if ( foo == bar )
^ ^ ^
The marked spaces should be ommitted to produce:
if(foo == bar)
================================================================================
Header Organization
================================================================================
Member variables should always be private and prefixed with "m_". Accessors may
be inline in the headers. The organization of the members in a class should be
roughly as follows:
public:
public Q_SLOTS:
protected:
protected Q_SLOTS:
Q_SIGNALS:
private: // member funtions
private Q_SLOTS:
private: // member variables
If there are no private Q_SLOTS there is no need for two private sections, however
private functions and private variables should be clearly separated.
The implementations files -- .cpp files -- should follow (when possible) the
same order of function declarations as the header files.
Virtual functions should always be marked as such even in derrived classes where
it is not strictly necessary.
================================================================================
Whitespace
================================================================================
Whitespace should be used liberally. When blocks of code are logically distinct
I tend to put a blank line between them. This is difficult to explain
systematically but after looking a bit at the current code organization this
ideally will be somewhat clear.
Also I tend to separate comments by blank lines on both sides.
================================================================================
Pointer and Reference Operators
================================================================================
This one is pretty simple. I prefer "Foo *f" to "Foo* f" in function signatures
and declarations. The same goes for "Foo &f" over "Foo& f".
================================================================================
There are likely things missing here and I'll try to add them over time as I
notice things that are often missed. Please let me know if specific points are
ambiguous.
Scott Wheeler <wheeler@kde.org>
|
