/
Contributing
101 lines (94 loc) · 4.8 KB
/
Contributing
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
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 Github issues page at
https://github.com/JHGuitarFreak/UQM-MegaMod/issues
contains any comments on what you're planning to do.
- Discuss in advance what you're planning to do, with the core team.
The best place to do this is on The New Alliance of Free Stars Discord server
https://discord.gg/rtaZH7cq8e
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.
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
(MSVS 2022 & GCC 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
the commit history 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 pull requests.
That way, there's a bigger chance the patch can be automatically applied
successfully against modified files.
- Make the patches against the current git commit.
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:
- 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.
Modified for MegaMod by JHGuitarFreak, 2024-04-18.