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 most of the requirements of the Free Software
Foundation Coding standards (which are currently available at
https://www.gnu.org/prep/standards/standards.html ).
We also follow most of the FSF guidelines, with the huge and explicit
exception of the style guidelines.
Developers may suggest deviations from the FSF
style recommendations, which will be considered by open discussion on
the Monitoring Plugins devel mailing list or the Github Pull Request.
Any such deviations should be
applied to the entire code base to ensure consistency.

The style guideline is the following:
Whatever clang-format does with the configuration file available (.clang-format)
Apart from that, code should naturally be readable and easy to understand.

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.