Phred

I saw this comment in CGI::Simple code:
# this module is both strict (and warnings) compliant, but they are only used
# in testing as they add an unnecessary compile time overhead in production.

There are a couple of other modules out there that imply "use strict;", such as Moose.

I don't know about the "unnecessary compile time overhead" but I don't have a problem with developing with warnings and strict enable and then turning it off in production.

What would be an argument against that behavior?

1) Did somebody benchmark a recent Perl to test the assertion they slow things down? Possibly they do - I don't know.

2) Can the app be moved to a persistent environment where that argument is irrelevant?
If not, why not :-)?

3) Is it a case of premature optimization?

I am guessing you should leave warnings on because they are just that "warnings" and maybe signs that you need to test areas of your code that your test suite didn't.

Actually there is a case to be made for turning warnings off in production. (You don’t want log files to overflow with useless messages just because you upgraded eg. some modules or perl and your tests didn’t catch the issue.)

But at least the refs stricture should stay on at all times. Turning it off in production means that your code is suddenly no longer safe from symbolic references if there is a bug that misinterprets user data.

In any case the overhead of strict is negligible.

I concur with Aristotle that there's an excellent case for leaving warnings off in production.

I actually leave warnings off in development as well, and turn it on in test scripts with

#!/usr/bin/perl

BEGIN {
$^W = 1;
}

There's also a good case for leaving warnings on in production, and ensuring that log files/cron STDERR emails are kept tidy by either fixing code or explicitly ignoring unavoidable warnings from sections of code or noisy modules (PDF::API2 being our main offender). A number of bugs have been caught by warnings (e.g. uninitialised values) when in production.

For my part, I did explicit say “a case” – and then not even “a good case”. :-) Because there are two sides to that coin, and yes, your argument presents part of the other.

What I was aiming for though is the contrast that no such case can be made for turning off strictures in production, and a strong case can in fact be made against turning off the refs stricture in particular.