aboutsummaryrefslogtreecommitdiffstats
path: root/doc/CODING-GUIDELINES
blob: fc66c64e9116860ea5677b9fb8a291ed535c2b22 (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
62
63
64
65
66
67
68
69
70
71
72
73
Asterisk Patch/Coding Guidelines

To be accepted into the codebase, all non-trivial changes must be
disclaimed to Digium or placed in the public domain. For more information
see http://bugs.digium.com

Patches should be in the form of a unified (-u) diff.

All code, filenames, function names and comments must be in ENGLISH.

Do not declare variables mid-function (e.g. like GNU lets you) since it is
harder to read and not portable to GCC 2.95 and others.

Don't annotate your changes with comments like "/* JMG 4/20/04 */";
Comments should explain what the code does, not when something was changed
or who changed it.

Don't make unnecessary whitespace changes throughout the code.

Don't use C++ type (//) comments.

Try to match the existing formatting of the file you are working on.

Functions and variables that are not intended to be global must be
declared static.

Function calls and arguments should be spaced in a consistent way across
the codebase.
GOOD: foo(arg1, arg2);
GOOD: foo(arg1,arg2);	/* Acceptable but not preferred */
BAD: foo (arg1, arg2);
BAD: foo( arg1, arg2 );
BAD: foo(arg1, arg2,arg3);

Following are examples of how code should be formatted.

Functions:
int foo(int a, char *s)
{
	return 0;
}

If statements:
if (foo) {
	bar();
} else {
	blah();
}

Case statements:
switch (foo) {
case BAR:
	blah();
	break;
case OTHER:
	other();
	break;
}

No nested statements without braces, e.g. no:

for (x=0;x<5;x++)
	if (foo) 
		if (bar)
			baz();

instead do:
for (x=0;x<5;x++) {
	if (foo) {
		if (bar)
			baz();
	}
}