CODING

   1 The following guidelines are intended to aid programmers in creating
   2 code that is consistent with the existing core plugins.
   3
   4 The primary goals of these standards are internal consistency, and
   5 readability in a wide range of environments.
   6
   7
   8 1. C Language Programming
   9
  10 All code should comply with the requirements of the Free Software
  11 Foundation Coding standards (which are currently available at
  12 http://www.gnu.org/prep/standards_toc.html). We also follow most of
  13 the FSF guidelines. Developers may suggest deviations from the FSF
  14 style recommendations, which will be considered by open discussion on
  15 the Monitoring Plugins devel mailing list. Any such deviations will
  16 apply to the entire code base to ensure consistency.
  17
  18 Currently, the exceptions to FSF recommendations are roughly equivalent
  19 to GNU indent with invoked as 'indent -ts 2 -br'. Specifically, the
  20 exceptions are as follows:
  21
  22 a) leading white space for a statement should be formatted as tabs,
  23 with one tab for each code indentation level.
  24
  25 b) in statement continuation lines, format whitespace up to the column
  26 starting the statement as tabs, format the rest as spaces (this
  27 results in code that is legible regardless of tab-width setting).
  28
  29 c) with the exception of the above, tabs should generally be avoided
  30
  31 d) when tab width is 2 spaces, line-length should not exceed 80
  32 characters
  33
  34 e) The opening brace of an if or while block is on the same line as
  35 the end of the conditional expression (the '-br' option).
  36
  37
  38 2. Perl Language Programming
  39
  40 Taken from the O'Reilly book "Programming Perl" (3rd edition, pages 604-606) with
  41 modifications for clarity and to cohere with C coding standards.
  42
  43 *) Always check the return code of system calls.
  44
  45 a) Use tab indentation.
  46
  47 b) Put space before the opening brace of a multiline block.
  48
  49 c) A short block may be put on one line, including braces.
  50
  51 d) Never omit the semicolon.
  52
  53 e)  Surround most operators with space.
  54
  55         $x = 5;    # do this
  56         $y=5;      # don't do this
  57
  58 f) Surround a "complex" subscript (inside brackets) with space.
  59
  60 g) Put empty lines between chunks of code that do different things.
  61
  62 *) Always check the return code of system calls.
  63
  64 h) Put a newline between closing brace and else or elsif.
  65
  66 i) Do not put space between a function name and its opening parenthesis.
  67
  68 j) Do not put space before a semicolon.
  69
  70 k) Put space after each comma.
  71
  72 l) Break long lines after an operator (but before 'and' and 'or', even when
  73 spelled as && and ||)).
  74
  75 *) Always check the return code of system calls.
  76
  77 m) Line up corresponding items vertically.
  78
  79 n) Use redundant parentheses only where it increases readability.
  80
  81 o) An opening brace should be put on the same line as its preceding keyword,
  82 if  possible; otherwise, line them up vertically.
  83
  84         while ($condition) {
  85                 # do something
  86         }
  87
  88         while ($this_condition and $that_condition and $some_other_condition
  89                and $this_really_really_really_long_condition)
  90         {
  91                 # do something
  92         }
  93
  94 p) Do things the most readable way. For instance:
  95
  96         open(FOO, $foo) or die "Can't open $foo: $!";
  97
  98 is  better than
  99
 100         die "Can't open $foo: $!" unless open(FOO, $foo);
 101
 102 because the second way hides the main point of the statement in a modifier.
 103
 104 q) Just because an operator lets you assume default arguments doesn't mean
 105 that you should always use them. The defaults are there for lazy programmers
 106 writing one-shot, non-shared programs. If you want your program to be readable,
 107 consider supplying the argument.
 108
 109 r) Choose mnemonic identifiers. That is, don't name your variables $h, $c
 110 and $w. Try $hostaddress, $critical and $warning instead ($host, $crit and
 111 $warn is OK too).
 112
 113 s) Use underscore to split words in long identifiers. That is, use
 114 $service_port instead of $ServicePort as the former is much more readable.
 115
 116 *) Always check the return code of system calls.