in reply to turn off strict for production code

The if pragma module would do the trick:

use if $ENV{'DEVELOPMENT'}, strict;

[download]

Your first snippet didn't work because use strict occurs at compile-time (even if the check is only done at run-time).

Your second snippet didn't work because use strict is file and block scoped.

Turning off strict in production is a bad idea. You can quickly check all your files for strict compliance by using perl -c script.pl and perl -c module.pm, so there's no reason for a customer to find a strict error. In fact, if the customer finds a strict error, it means that file was never tested at all!!

Replies are listed 'Best First'.
Re^2: turn off strict for production code
by blahblahblah (Priest) on Sep 12, 2005 at 15:48 UTC
    Thank you both for the 'if' pragma suggestion.

    As for "perl -c" catching all "strict" errors, these files definitely compile, but it doesn't catch problems like the following: 

    use strict;
my $try = $ARGV[0];
if ($try)
{
    my $var = 'joe';
    $$var = 'test';
}

    [download]
[reply]
[d/l]

      Of course! I was only thinking of use strict 'vars'. This is one morning where I should have stayed in bed.

      In any case, I'd rather find this error definitely, rather than have the program fail in wierd and unpredicatable ways. It's a question of whether you want to create no data (by dying from strict) or create bad data (by referencing variables that don't exist). I'd vote for no data over bad data any day of the week.

[reply]
[d/l]
        In any case, I'd rather find this error definitely, rather than have the program fail in weird and unpredictable ways.
        Using symbolic references is bad form, but it doesn't necessarily mean there's a bug to be found.
[reply]

In Section Seekers of Perl Wisdom