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
|
These are some guidelines for people who want to contribute to the code.
Don't be surprised if your contributions get tossed in the bit-bucket if you
do not follow them. We don't want to be unfriendly, but our time is limited.
These guidelines are there so that you won't waste both our and your time.
Before making changes:
- Read this entire document
- See if the Bugzilla bug database at
http://bugs.uqm.stack.nl/ contains any comments on what you're planning
to do.
- Make sure you're using the most recent Subversion version
- Discuss in advance what you're planning to do, with the core team.
The best place to do this is on #sc2 on irc.freenode.net.
This prevents you from wasting your time when
- someone else is already working on your issue
- we've got a very clear idea of how we want it to be
- the code you're planning to change will be completely rewritten
in the near future.
- Don't bother on adding "great ideas" you have for the game;
Our current goal is a straight port. The code is GPL, so feel free
to start your own modified version, but don't bother sending them
in for the official version.
Making changes:
- Follow the coding style of the existing source. You don't have to like it,
we don't even always do, but we've accepted this as our standard. The main
reason is that this is very close to the original style.
Trying to start a discussion about the standard is pointless and is
definitely NOT appreciated.
- Use 1 tab per indentation level
- Use no more than 76 chars on a line, when using a tab size of 4.
- Use 2 extra indentation levels for the continuation of a broken line,
like this:
if (blablablabla || foobar ||
zut || linefiller ||
morezut)
printf ("Yeah!\n");
- Don't use tabs for anything but indenting. If you would, and someone
has a different tab size, or something in the line changes, other stuff
on the line may or may not move, depending on where on the line it is.
If you for instance want to align a list of declarations, use spaces,
like this:
{
<TAB>long l,
<TAB> m;
<TAB>int i;
}
(Though in this particular case, I personally would repeat the 'long',
or place l and m on the same line)
- Put { on a separate line, both for the start of a function and
for the start of a block.
- one space around binary operators, and after commas.
- one space between the function name and following '(', both in
declaration and call (unusual as it is).
- one space after 'if', 'while', 'do', 'for' and 'switch'.
- even for short selections or repetitions, don't have the statement
to execute on the same line as the guard. So:
if (a)
a--;
- Use unix-style line-endings, that is '\n' only. If the editor you're
using doesn't support this, please pass your code through a conversion
program before submitting.
- Don't hurry into changing code. All code is there for a reason. Be sure
you understand that reason before changing it. Don't just go recode a part
because you think that would be easier than trying to understand the
original. If you don't have the skills or patience to do so, this is not
the place for you.
- Only use portable functions. The code is intended to work on Windows
(MSVC 6), Linux (GCC 4), FreeBSD (GCC 4) and MacOS X (GCC 4).
Try to avoid unnecessary system-dependant code, but use #ifdefs if you
really have to.
- No shortcuts. Don't assume anything about user input (like the length),
and check the return values of functions that may fail.
- Your code shouldn't cause any compile-time or runtime-warnings. We know
the current source is far from warning-free, but those should be removed
eventually and we don't want to make it worse.
- Don't add comment lines saying things like "This line added by <me>".
These comments only foul the code and don't add anything for people
reading it. You'll still be credited in the Changelog, and for large
contributions (or many small ones) in the authors list. We have
Subversion for when we need to find out when what changes were made.
Making the patches:
- One issue per patch.
We need to keep track of what's being changed, and multiple changes
in one patch will make that more difficult.
Also, we might want to accept one patch, and reject the other.
- Use unified diffs.
That way, there's a bigger chance the patch can be automatically applied
successfully against modified files.
- Make the patches against the current Subversion tree.
Test the patches:
- If possible, test your changes both on Windows and a *nix platform, or
send them to someone to test them for you.
Getting the patches committed:
- Either attach the patches to the appropriate bug report in the Bugzilla
bug database or send them to one of the committers, in plain-text format.
This can be done by email, DCC from within the #sc2 channel, or by
mentioning an URL where we can get the patch.
The committers are listed below (in alphabetical order), with their
particular field of expertise with the source. Though all of us
should have enough experience to deal with most issues not explicitly
mentioned.
Serge van den Boom (svdb at stack.nl), SvdB at #sc2
- Resource system
- 3DO historical code
- *nix build system
- Netplay
- General issues (particularly on *nix)
Mika Kolehmainen (mk at kapsi.fi), Gwl at #sc2
- Graphics
- Sound
- General issues
Michael Martin (mcmartin at mail.com), McMartin at #sc2
- Threading
- Graphics
- Input system
- In-game configuration
- General issues
Alex Volkov (codepro at usa.net), fossil at #sc2
- Graphics
- Sound (particularly MixSDL)
- Alien communications code
- General issues
- Only submit code that can be used under the GPL. By submitting code you
hold the copyright to, you agree that it can be used under the term of
the GPL. If you use code by someone else, make sure that it can be used
under the GPL and let us know, so that adequate credit can be given.
Initial version of this file by Serge van den Boom, 2002-12-05.
|
