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
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
165
166
|
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.
Roughly, Asterisk coding guidelines are generally equivalent to the
following:
# indent -i4 -ts4 -br -brs -cdw -cli0 -ce -nbfda -npcs -npsl foo.c
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();
}
}
Make sure you never use an uninitialized variable. The compiler will
usually warn you if you do so.
Name global variables (or local variables when you have a lot of them or
are in a long function) something that will make sense to aliens who
find your code in 100 years. All variable names should be in lower
case.
Make some indication in the name of global variables which represent
options that they are in fact intended to be global.
e.g.: static char global_something[80]
When making applications, always ast_strdupa(data) to a local pointer if
you intend to parse it.
if(data)
mydata = ast_strdupa(data);
Always derefrence or localize pointers to things that are not yours like
channel members in a channel that is not associated with the current
thread and for which you do not have a lock.
channame = ast_strdupa(otherchan->name);
If you do the same or a similar operation more than 1 time, make it a
function or macro.
Make sure you are not duplicating any functionality already found in an
API call somewhere. If you are duplicating functionality found in
another static function, consider the value of creating a new API call
which can be shared.
When you achieve your desired functionalty, make another few refactor
passes over the code to optimize it.
Before submitting a patch, *read* the actual patch file to be sure that
all the changes you expect to be there are, and that there are no
surprising changes you did not expect.
If you are asked to make changes to your patch, there is a good chance
the changes will introduce bugs, check it even more at this stage.
Avoid needless malloc(),strdup() calls. If you only need the value in
the scope of your function try ast_strdupa() or declare struts static
and pass them as a pointer with &.
If you are going to reuse a computable value, save it in a variable
instead of recomputing it over and over. This can prevent you from
making a mistake in subsequent computations, make it easier to correct
if the formula has an error and may or may not help optimization but
will at least help readability.
Just an example, so don't over analyze it, that'd be a shame:
const char *prefix = "pre";
const char *postfix = "post";
char *newname = NULL;
char *name = "data";
if (name && (newname = (char *) alloca(strlen(name) + strlen(prefix) + strlen(postfix) + 3)))
snprintf(newname, strlen(name) + strlen(prefix) + strlen(postfix) + 3, "%s/%s/%s", prefix, name, postfix);
vs
const char *prefix = "pre";
const char *postfix = "post";
char *newname = NULL;
char *name = "data";
int len = 0;
if (name && (len = strlen(name) + strlen(prefix) + strlen(postfix) + 3) && (newname = (char *) alloca(len)))
snprintf(newname, len, "%s/%s/%s", prefix, name, postfix);
Use const on pointers which your function will not be modifying, as this
allows the compiler to make certain optimizations.
== CLI Commands ==
New CLI commands should be named using the module's name, followed by a verb
and then any parameters that the command needs. For example:
*CLI> iax2 show peer <peername>
not
*CLI> show iax2 peer <peername>
|
