blob: 51058c8b77651956acd13c9839c01907507a61e1 (
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
|
$Id$
__________ __ ___.
Open \______ \ ____ ____ | | _\_ |__ _______ ___
Source | _// _ \_/ ___\| |/ /| __ \ / _ \ \/ /
Jukebox | | ( <_> ) \___| < | \_\ ( <_> > < <
Firmware |____|_ /\____/ \___ >__|_ \|___ /\____/__/\_ \
\/ \/ \/ \/ \/
Contribution Policies
In order for the project to run as smoothly as possible, it's best if all
contributors adhere to a few simple conventions:
Language
--------
Write all code in C. Sometimes assembly is faster, but C is always more
readable and maintainable.
Language features
-----------------
Write normal C code. Don't redefine the language. No new types (structs are
structs, not typedefs), no C++isms or Javaisms. Also, avoid using "const".
Names
-----
Variables and function names should be all lower case.
Preprocessor symbols should be all uppercase.
Style
-----
When changing code, follow the code style of the file you are editing.
When writing new files, you may use the brace placement style of your choice.
Always indent your code with four spaces. Don't use TAB characters, as that
will mess up code display in CVS, printing, and a zillion other places.
Keep lines below 80 columns length. Use whitespace and newlines to make the
code easy to browse/read.
Text format
-----------
Use "unix style" line feeds: "LF" only. Do not use "CR+LF".
Patches
-------
Create a patch using 'cvs diff -ub'.
Trim your patches so they only contain relevant changes.
Submit all patches to the mailing list.
Put [PATCH] first on the subject line of your mail.
If the patch is very large (>50k), gzip it before you send it.
|
