Project

General

Profile

Coding Styleguide » History » Version 4

quintus, 03/21/2020 10:41 AM

1 1 quintus
# Coding Styleguide
2
3 2 quintus
{{toc}}
4
5 1 quintus
Those who have worked on the TSC project will remember the dreaded discussion about coding style. This project will avoid the trap by using a consistent coding style right from the start. It is outlined in this document.
6
7
The game's source code is formatted according to the [1TBS](https://en.wikipedia.org/wiki/Indentation_style#Variant:_1TBS_(OTBS)) style, which is a variant of K&R, with slight adjustments. Details are documented below.
8
9
In general, try to keep your code readable. Specifically, it is often useful to leave empty lines to separate logically grouped statements from one another.
10 2 quintus
11 1 quintus
12
## Indentation, line length
13
14
Source code is indented with 4 spaces, tabs are not used. Lines should be broken around 80 characters, and the resulting continuation lines should be indented so that it makes sense to look at. Example:
15
16
~~~~~ c++
17
if (somecondition) {
18
    thisIsAVeryLongFunctionName(this_is_a_parameter,
19
                                this_is_another_parameter,
20
                                third_parameter);
21
}
22
~~~~~
23
24
## Commentary
25
26
Semantically, comments should normally reflect why code is written the way it is. Normally it is not required to explain what code does, unless it is an exceptionally complex part. Syntactically, use `//` for one and two lines of comments. Starting with the third line, comments should use the bock syntax `/* ... */`. In the block syntax, align each star with the one on the preceeding line. Terminate the comment block on the last line of the comment.
27
28
~~~~~ c++
29
// Careful: this is used in foobar() as well
30
31
/* This code is designed to specifically fit the purpose of an example.
32
 * It was not at all easy to come up with all this text, but for the
33
 * sake of an example, it was required to do so. */
34
~~~~~
35
36
### Documentation comments
37
38
Where Doxygen is used to generate documentation, use Doxygen's `///` markers for short and the `/**` markers for long documentation. Other than that, the above advice applies.
39
40
## Case of identifiers
41
42 4 quintus
* Macros are ALL_IN_CAPS. They need to stand out.
43
* Class identifiers use CamelCase. Structure and enum identifiers are snake_case (makes it easy to spot whether this type is copy-by-value or copy-by-reference: every lowercase type is copy-by-value).
44
* Member function identifiers are CamelCase. This keeps function names short (they tend to be longer than member variable names).
45
* All variables and constants (unless the constants are macros, see above) are snake_case. This includes static member variables, even if they are constant. This way a non-function member is easily identifiable by being lowercase. The different variable types are distinguished by the prefix (see [below](#Abbreviated-Hungarian-Notation)).
46
47
~~~~~~ c++
48
#define THIS_IS_A_MACRO(x) foo_ ## x
49
50
struct my_struct;
51
enum class my_enum;
52
53
class MyClass {
54
    MyClass();
55
    ~MyClass();
56
57
    void MemberFunction();
58
    static int StaticMemberFunction();
59
60
    int m_member_variable;
61
    static int static_member;
62
};
63
64
void foo() {
65
    static int local_static_variable;
66
    float normal_local_var = 3.5f;
67
    // ...
68
}
69
~~~~~~
70 1 quintus
71
## Abbreviated Hungarian Notation
72
73
Identifiers of variables and constants begin with a short sequence of characters that encodes some important information about the variable in question. This is called [Hungarian Notation](https://en.wikipedia.org/wiki/Hungarian_notation), but in full, it is cumbersome to read and leads to long identifier names. The following prefix characters have been chosen with respect to two goals: Make variable scope immediately visible, and warn of "unusual" types.
74
75
| Prefix | Meaning                                                          |
76
|--------+------------------------------------------------------------------|
77
|        | No prefix: Local variable                                        |
78
| m      | Member variable                                                  |
79
| s      | File-local variable                                              |
80
| g      | Global variable                                                  |
81
| p      | Variable holds a pointer (both raw and managed pointers)         |
82
| a      | Variable holds a raw array (not: vector or other C++ containers) |
83
84
The scope prefix comes before the type prefix. Thus, `mp_foo` is a member variable holding a pointer, and `ga_argv` is a global variable holding a raw C array.
85
86
## Compound Statements
87
88
The opening brace resides on the same line as the statement it applies to, regardless of whether this is a function, a control flow statement, or a class or enum declaration. The closing brace has a line on its own to ensure it is easily spottable where a block ends.
89
90
~~~~~~~~~~~ c++
91
class Foo {
92
};
93
94
if (condition) {
95
    // ...
96
}
97
98
while (condition) {
99
    // ...
100
}
101
102
void main() {
103
    // ...
104
}
105
~~~~~~~~~~~
106
107
The rare case of a terminal `while` has the `while` after the closing brace on the same line.
108
109
~~~~~~ c++
110
{
111
    // ...
112
} while (condition)
113
~~~~~~~
114
115
## Brace Cuddling
116
117
In an if/elsif/else statement, braces are cuddled to keep code compact.
118
119
~~~~~~~~~~ c++
120
if (condition1) {
121
    // ...
122
} else if (condition2) {
123
    // ...
124
} else {
125
    // ...
126
}
127
~~~~~~~~~~~
128
129
## Braces around short statements
130
131 3 quintus
Do not leave out braces even for one-line statements. This should prevent any accidental cutting of conditional clauses.
132 1 quintus
133
~~~~~~~~~ c++
134 3 quintus
// Short: required braces
135
if (condition) {
136 1 quintus
    doit();
137 3 quintus
}
138 1 quintus
139 3 quintus
// Also requires braces
140
if (condition1) {
141 1 quintus
    doit();
142 3 quintus
} else { // Thanks to brace cuddling, this is not as bad as in pure K&R
143 1 quintus
    doother();
144 3 quintus
}
145 1 quintus
146 3 quintus
// Requires braces in any style to keep clarity
147 1 quintus
if (condition1) {
148
    doit();
149
} else {
150
    doother1();
151
    if (condition2) {
152
        something();
153
    }
154
    else {
155
        andmore();
156
    }
157
}
158
~~~~~~~~~
159
160
## Parantheses and spacing
161
162
Between a keyword and the opening paranthesis is exactly one space. Between the closing paranthesis and the opening curly brace is exactly one space as well. *There is no space between a function name and the opening paranthesis of its argument list*, neither in declaration nor in calling of a function.
163
164
~~~~~~~~ c++
165
void foo() { // No space between function name and (, but one space between ) and {
166
    if (condition) { // One space between keyword if and (, and one space between ) and {
167
        // ...
168
    }
169
}
170
~~~~~~~~