-><- -><- -><- -><- -><-
All things are Perfect
    To every last Flaw
    And bound in accord
         With Eris's Law
 - HBT; The Book of Advice, 1:7

Not only do I rarely engage in pre-condition checking, I would discourage it. I'm sure people will disagree with me on this, but it seems to go against the way I want my code to go: the sub does what it says it does, and nothing more. I include documentation of the pre-conditions so that people calling my sub will know what they can send in - but I'm not about to tell them that they can't break the rules - I'm only stating that these are the only conditions which I'm sure my code operates correctly under (and even then I'm wrong sometimes).

I think it's analogous to a warranty - you see the terms of the warranty (the pre-condition), and it's up to you to handle the item correctly (passing correctly formatted / sequenced variables). If you choose not to, well, you might get what you want, or you might not. But you broke the rules, so I'm not gonna guarantee you anything in this case.

Don't let my ranting discourage you, though - do what you feel comfortable with. Certainly, checking that data is correct makes things nice for the user, but at the same time, you restrict the user's freedom. There's no real clear direction as to which is better - it's all about finding a good balance to that, I guess...

Update: I should point out that I am in no way saying that checking input is a bad idea - I mean, if perl didn't choke on syntax errors, you'd never have seen me here on PM. I just felt the need to bring up the point that adding in tons of input checks can result in your code becoming far too complicated, and can cause you to lose sight of your objective.

His Royal Cheeziness

I see your point. I would say this, however... In order to make an application robust, I would say use the condition checking, and when making a utility (like a module), let it be flexible....

_________________________________________
E-Bitch
Tempora Mutantur Nos et Mutamur in Illis
"The Times are Changed Even as We are Changed in Them"

I call that a precondition regardless of whether the code checks it or not. Your docs list what the function assumes, rather than letting the user guess or incorrectly mix up implementation details with specifications.

Years ago, I formalized a way to include preconditions in my C++ class documentation in a simple and useful way.

I specify which conditions are assumed vs validated. An assumed precondition means that you the caller better get it right, or the function will not behave as advertised. A validated precondition means that the code will catch this misuse (whether by throwing an exception, returning an error code, or whatever).

The concept of preconditions is very valuable for documentation, not just for making code super-robust. It lets you note the allowed range or restrictions on a function without cluttering up the prose description.

Checking some kinds of preconditions are done in the normal way: if n is greater than m, throw an error; etc. For ones that are not normally validated but you want in debug mode, in C++ the assert macro is often used. Without using a text preprocessor or waiting for Perl 6's lazy evaluation, I don't see an easy way to turn off checking by throwing a switch. The switch would be present in each statement: if ($debug && expensive_sanity_check(x)) ...

—John

Without using a text preprocessor or waiting for Perl 6's lazy evaluation, I don't see an easy way to turn off checking by throwing a switch. The switch would be present in each statement: if ($debug && expensive_sanity_check(x)) ...

Use a constant:

use constant DEBUG => 0; ... sub foo { sanity_check(...) if DEBUG; } [download]

This has the nice effect of optimizing away the entire sanity check statement in production code, without employing a preprocessor/text-filter.

   MeowChow                                   
               s aamecha.s a..a\u$&owag.print

Without using a text preprocessor or waiting for Perl 6's lazy evaluation, I don't see an easy way to turn off checking by throwing a switch.

That's why I like Carp::Datum. It comes with a pre-condition stripper that you can use once you are read to go into production.

   MeowChow                                   
               s aamecha.s a..a\u$&owag.print

--
Mark Dominus
Perl Paraphernalia