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
|
The following guidelines are intended to aid programmers in creating
code that is consistent with the existing core plugins.
The primary goals of these standards are internal consistency, and
readability in a wide range of environments.
1. C Language Programming
All code should comply with the requirements of the Free Software
Foundation Coding standards (which are currently available at
http://www.gnu.org/prep/standards_toc.html). We also follow most of
the FSF guidelines. Developers may suggest deviations from the FSF
style recommendations, which will be considered by open discussion on
the nagiosplug-devel mailing list. Any such deviations will apply to
the entire code base to ensure consistency.
Currently, the exceptions to FSF recommendations are roughly equivalent
to GNU indent with invoked as 'indent -ts 2 -br'. Specifically, the
exceptions are as follows:
a) leading white space for a statement should be formatted as tabs,
with one tab for each code indentation level.
b) in statement continuation lines, format whitespace up to the column
starting the statement as tabs, format the rest as spaces (this
results in code that is legible regardless of tab-width setting).
c) with the exception of the above, tabs should generally be avoided
d) when tab width is 2 spaces, line-length should not exceed 80
characters
e) The opening brace of an if or while block is on the same line as
the end of the conditional expression (the '-br' option).
2. Perl Language Programming
Taken from the O'Reilly book "Programming Perl" (3rd edition, pages 604-606) with
modifications for clarity and to cohere with C coding standards.
*) Always check the return code of system calls.
a) Use tab indentation.
b) Put space before the opening brace of a multiline block.
c) A short block may be put on one line, including braces.
d) Never omit the semicolon.
e) Surround most operators with space.
$x = 5; # do this
$y=5; # don't do this
f) Surround a "complex" subscript (inside brackets) with space.
g) Put empty lines between chunks of code that do different things.
*) Always check the return code of system calls.
h) Put a newline between closing brace and else or elsif.
i) Do not put space between a function name and its opening parenthesis.
j) Do not put space before a semicolon.
k) Put space after each comma.
l) Break long lines after an operator (but before 'and' and 'or', even when
spelled as && and ||)).
*) Always check the return code of system calls.
m) Line up corresponding items vertically.
n) Use redundant parentheses only where it increases readability.
o) An opening brace should be put on the same line as its preceding keyword,
if possible; otherwise, line them up vertically.
while ($condition) {
# do something
}
while ($this_condition and $that_condition and $some_other_condition
and $this_really_really_really_long_condition)
{
# do something
}
p) Do things the most readable way. For instance:
open(FOO, $foo) or die "Can't open $foo: $!";
is better than
die "Can't open $foo: $!" unless open(FOO, $foo);
because the second way hides the main point of the statement in a modifier.
q) Just because an operator lets you assume default arguments doesn't mean
that you should always use them. The defaults are there for lazy programmers
writing one-shot, non-shared programs. If you want your program to be readable,
consider supplying the argument.
r) Choose mnemonic identifiers. That is, don't name your variables $h, $c
and $w. Try $hostaddress, $critical and $warning instead ($host, $crit and
$warn is OK too).
s) Use underscore to split words in long identifiers. That is, use
$service_port instead of $ServicePort as the former is much more readable.
*) Always check the return code of system calls.
|