[Nagiosplug-devel] Nagios:Plugin feedback

[Andreas Ericsson]

Thomas Guyot-Sionnest wrote:
>> -----Original Message-----
>> From: nagiosplug-devel-bounces at lists.sourceforge.net 
>> [mailto:nagiosplug-devel-bounces at lists.sourceforge.net] On 
>> Behalf Of Andreas Ericsson
>> Sent: January 19, 2007 8:56
>> To: Nagios Plugin Development Mailing List
>> Subject: Re: [Nagiosplug-devel] Nagios:Plugin feedback
>>
>> Thomas Guyot-Sionnest wrote:
>>> There's many useful functions in the C API for Nagios 
>> plugins. I believe
>>> it wouldn't be a bad idea to have the same kind of function directly
>>> into Nagios::Plugin. By minimizing the use of external modules, you
>>> simplify plugin deployment.
>>>
>>> Nagios::Plugin could itself load external modules to do the 
>> checks, but
>>> those dependencies would be installed along with Nagios::Plugin.
>>>
>>> What I'm starting to realize is that there's nothing to check the
>>> validity of arguments. In C you have all those functions:
>>>
>>> is_integer
>>> is_intpos
>>> is_intneg
>>> is_intnonneg
>>> is_intpercent
>>> is_numeric
>>> is_positive
>>> is_negative
>>> is_nonnegative
>>> is_percentage
>>>
>> Please, pretty please, don't mention those. They are 
>> extremely bad examples
>> of C programming. ALL of them can, even from the callers perspective
>> be replaced with shorter versions that are already C89 compliant.
>>
>> Most of them also duplicate checks already implemented in the 
>> libc functions
>> and *NONE* of them return the computed value to the caller. 
>> Each time you see
>> one of those functions used, you will know for a fact that 
>> several operations
>> are carried out at least twice. It's usually worse than that, 
>> because it's often
>> done in subtly (and pointless) different ways that the 
>> compiler can't optimize
>> away.
> 
> Oh, Thanks. I'm not a very experienced Perl programmer, and even worse C
> programmer, so that's good to know.
> 
> It would be nice then to know the replacements, and possibly start a project
> to clean up those (And any other that need to go) so we can eventually
> remove that from utils.c/h. Or is there any reason why we wouldn't want to
> do that?
> 

It works, so there's no real *need* to modify it (we're not coding demoes for C64
here, so we have the option of doing nothing while the computer does loads).
That's no excuse to encourage it though.

> This could be for a future v2 release, among with newer style tresholds
> args, etc... Meanwhile the devlopper guidelines could mention which
> functions not to use, and the recommended replacements. I often refer to
> other plugins to decide how I should do things and they apparently aren't
> always good examples.
> 

Not always, but sometimes. In the end you will decide to do things one way
or another anyway, and if it *works* people won't whine at you.

Just follow these guidelines and I'm sure you'll do OK.

* Don't compute values you don't need.
* Don't throw away computed values.
* Don't compute values twice.
* Don't be overly anal (is_ipaddr()/is_hostname() discussion).
* Don't get overly clever with macros and wrapper functions.
* Don't bloat your functions. One function well written, one task done well.
* Don't use non-portable functions/procedures.
* Don't break any of the above unless there are compelling reasons to do so. ;-)
* Don't comply to a too-old standard (C99 is 8 years old in May, fe).

I'm sure there are more complete lists on the web, and almost certainly some
that are particular to perl as opposed to this one that applies to programming
in general.

-- 
Andreas Ericsson                   andreas.ericsson at op5.se
OP5 AB                             www.op5.se
Tel: +46 8-230225                  Fax: +46 8-230231