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 most of the requirements of the Free Software
  11 Foundation Coding standards (which are currently available at
  12 https://www.gnu.org/prep/standards/standards.html ).
  13 We also follow most of the FSF guidelines, with the huge and explicit
  14 exception of the style guidelines.
  15 Developers may suggest deviations from the FSF
  16 style recommendations, which will be considered by open discussion on
  17 the Monitoring Plugins devel mailing list or the Github Pull Request.
  18 Any such deviations should be
  19 applied to the entire code base to ensure consistency.
  20
  21 The style guideline is the following:
  22 Whatever clang-format does with the configuration file available (.clang-format)
  23 Apart from that, code should naturally be readable and easy to understand.
  24
  25 2. Perl Language Programming
  26
  27 Taken from the O'Reilly book "Programming Perl" (3rd edition, pages 604-606) with
  28 modifications for clarity and to cohere with C coding standards.
  29
  30 *) Always check the return code of system calls.
  31
  32 a) Use tab indentation.
  33
  34 b) Put space before the opening brace of a multiline block.
  35
  36 c) A short block may be put on one line, including braces.
  37
  38 d) Never omit the semicolon.
  39
  40 e)  Surround most operators with space.
  41
  42         $x = 5;    # do this
  43         $y=5;      # don't do this
  44
  45 f) Surround a "complex" subscript (inside brackets) with space.
  46
  47 g) Put empty lines between chunks of code that do different things.
  48
  49 *) Always check the return code of system calls.
  50
  51 h) Put a newline between closing brace and else or elsif.
  52
  53 i) Do not put space between a function name and its opening parenthesis.
  54
  55 j) Do not put space before a semicolon.
  56
  57 k) Put space after each comma.
  58
  59 l) Break long lines after an operator (but before 'and' and 'or', even when
  60 spelled as && and ||)).
  61
  62 *) Always check the return code of system calls.
  63
  64 m) Line up corresponding items vertically.
  65
  66 n) Use redundant parentheses only where it increases readability.
  67
  68 o) An opening brace should be put on the same line as its preceding keyword,
  69 if  possible; otherwise, line them up vertically.
  70
  71         while ($condition) {
  72                 # do something
  73         }
  74
  75         while ($this_condition and $that_condition and $some_other_condition
  76                and $this_really_really_really_long_condition)
  77         {
  78                 # do something
  79         }
  80
  81 p) Do things the most readable way. For instance:
  82
  83         open(FOO, $foo) or die "Can't open $foo: $!";
  84
  85 is  better than
  86
  87         die "Can't open $foo: $!" unless open(FOO, $foo);
  88
  89 because the second way hides the main point of the statement in a modifier.
  90
  91 q) Just because an operator lets you assume default arguments doesn't mean
  92 that you should always use them. The defaults are there for lazy programmers
  93 writing one-shot, non-shared programs. If you want your program to be readable,
  94 consider supplying the argument.
  95
  96 r) Choose mnemonic identifiers. That is, don't name your variables $h, $c
  97 and $w. Try $hostaddress, $critical and $warning instead ($host, $crit and
  98 $warn is OK too).
  99
 100 s) Use underscore to split words in long identifiers. That is, use
 101 $service_port instead of $ServicePort as the former is much more readable.
 102
 103 *) Always check the return code of system calls.