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
|
# Coding Style
## Introduction
We are trying to follow the coding style that is predominant in the old Warzone 2100 code.
Please use this style in your patches.
This means your code should look like this (note spaces, braces and line endings):
```cpp
void functionName(const char *variableName, int *anotherVar, STRUCTURE *psStruct)
{
if (variableName == NULL)
{
*anotherVar = 1 + 2 * (5 / 2);
}
else
{
*anotherVar = 1 + 2 * (atoi(variableName) / 2);
}
}
```
This is not considered "good" C++ style anymore, but we think consistency is good
for making the code easy to read, so we want to stick to the old style even for new
code and new patches.
Indentation for scope should use tabs, while indentation for lining up wrapped lines
should use tabs to align with the start of previous line, then spaces. This way the
code will look readable with any tab size. For example, when a line with a two-line
printf begins, use tab to indent it, then use tab then spaces to indent the following
line, like this (`\t` for tabs):
```cpp
\t\tprintf("some text on this line that got long",
\t\t "some more text on the next line");
```
## Guidelines
* Comment always why you do something if this is not obvious.
* Comment how you do it if it may be difficult to follow.
* Do not comment out code you want to remove. Just remove it. Git can always get it back.
* Always add braces following conditionals (`if`).
* Put curly braces on lines of their own
* Use `stdint.h` fixed size types (`uint32_t` etc.) when necessary, otherwise usual C types.
* Don't use Pumpkin's legacy basic types (`UDWORD` etc.) in new code.
* Try to avoid changing a ton of code when porting something C-ish to something more C++-ish
* Do not rewrite code to C++ just to rewrite stuff to C++
* Avoid templates unless they have clear benefit.
* We do not use exceptions.
* Inheritance is nice, but try to avoid unnecessary levels of abstraction.
* Make sure your patch does not add any new compiler warnings.
## Artistic Style
For astyle, save the following as "astyle":
```txt
suffix=none
indent=tab
indent-switches
pad-oper
unpad-paren
min-conditional-indent=0
mode=c
indent-preprocessor
```
and call astyle like:
```shell
astyle --options=astyle <files>
```
## Coding techniques
We want the code to be easily readable and accessible to newcomers. That means
keeping it simple, rather than writing the coolest possible code. Don't use
fancy C++ features if basic features can do the job just as well. Don't write
clever optimizations if it makes the code hard to read, unless you are in a
performance critical section of the code.
As a wise man once said: Debugging code is harder than writing code. So if you
are writing code as cleverly as possible, you are by definition too stupid to
debug it.
|
