diff options
| -rw-r--r-- | CODING | 80 |
1 files changed, 79 insertions, 1 deletions
@@ -4,6 +4,7 @@ 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 @@ -33,6 +34,83 @@ 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 -<To Be Written> +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. |