Beefy Boxes and Bandwidth Generously Provided by pair Networks
XP is just a number
 
PerlMonks  

turn off strict for production code

by blahblahblah (Priest)
on Sep 12, 2005 at 15:04 UTC ( [id://491277]=perlquestion: print w/replies, xml ) Need Help??

blahblahblah has asked for the wisdom of the Perl Monks concerning the following question:

Hi,

I work on a very large cgi program that until this year did not use strict at all. I know that's terrible, and I'm not looking to justify it. In fact we're trying to reform our ways, and that's what this post is about.

In our most recent version we finally added 'use strict;' to some files. We found a lot of errors during development and a few more during testing, and felt pretty confident by the time we released the version. However, since the release our customers have uncovered a few more errors (always because of symbolic references). I suspect more are lurking, and because we don't have any automated testing it's not likely that we'll find every combination of settings/inputs that cause these errors. That means our customers will find the problems, which is bad.

I'd like to keep strict on for development and testing and then comment it out in the final code that we ship. Is there an easy way to do this without actually keeping different versions of the code?

This gives a syntax error:

use strict if $ENV{'DEVELOPMENT'}
This doesn't get an error but it only affects the "if" block:
if ($ENV{'use_strict'}) { use strict; }

I'd like to keep the whole script (including the #! line) the same so that we can't accidentally send someone a patch in which we forgot to comment out strict. Anyone have an idea of how to do this?

-Joe

Replies are listed 'Best First'.
Re: turn off strict for production code
by dragonchild (Archbishop) on Sep 12, 2005 at 15:09 UTC
    use if $ENV{'DEVELOPMENT'} => 'strict';
    You'll need to install the if module.

    As for your larger question - why haven't you performed code reviews on these files? Why aren't you enabling strict within functions instead of files? I would strongly urge you to enable strict within functions until all functions in a given file have strict enabled, then enable strict for the file.

    And, always code reviews.


    My criteria for good software:
    1. Does it work?
    2. Can someone else come in, make a change, and be reasonably certain no bugs were introduced?
Re: turn off strict for production code
by ikegami (Patriarch) on Sep 12, 2005 at 15:11 UTC

    The if pragma module would do the trick:

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

    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!!

      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'; }

        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.

Re: turn off strict for production code
by pg (Canon) on Sep 12, 2005 at 15:30 UTC

    To step out your question a little bit... the if programa can be used against both programas and Modules:

    use if (1==1), Data::Dumper; #use if (1==0), Data::Dumper; print Dumper({});

    Comment out either of the first two lines to see the effect.

Re: turn off strict for production code
by talexb (Chancellor) on Sep 12, 2005 at 15:39 UTC
      I'd like to keep strict on for development and testing and then comment it out in the final code that we ship. Is there an easy way to do this without actually keeping different versions of the code?

    One way is to just comment out the use strict when you check the code into your revision control system. That way, when you install onto your Production servers, use strict will be disabled. When you develop, uncomment the same line after you check it out from your version control system.

    Having addressed your question, please check out this thread regarding using strict. Not using it can be compared to not wearing seat belts, not checking your chute before going skydiving, not wearing orange when hunting and not wearing a helmet when driving a motorcycle. I sure don't want to start a side thread based on those comparisons -- you already know that you should be using strict. You know that you should be doing testing. It's a philosophical thing -- figure out what you should be doing, then be that person.

    Good luck.

    Alex / talexb / Toronto

    "Groklaw is the open-source mentality applied to legal research" ~ Linus Torvalds

      Never expect a developer to change the file's settings on checkin/checkout reliably. "Oh, what I'm doing is just such a quick change, I'll skip that."

      You might think that checkin/checkout hooks are the answer. Under that scheme, you make the version control system tweak the code on checkin/checkout for you. Example: checking out to a developer box means "use strict;" checking out to test servers means "use strict;" checking out to production servers means "no strict." Until you forget to add or remove certain usernames from a list. And don't forget the heisenbugs which somehow only show up when there's no debugger around.

      No, version control is not a part of the code. Version control is insurance against mistakes and disasters, but not a tool which actively tunes your applications. Just because it's possible doesn't mean it's a good practice.

      --
      [ e d @ h a l l e y . c c ]

Re: turn off strict for production code
by Old_Gray_Bear (Bishop) on Sep 12, 2005 at 15:45 UTC
    Please satisfy my curiosity -- what benefit do you expect to derive from removing 'use strict;' from your production code? I didn't think that the overhead from enabling strictures was particularly onerous.

    ----
    I Go Back to Sleep, Now.

    OGB

      what benefit do you expect to derive from removing 'use strict;' from your production code?
      Quoting the OP...
      However, since the release our customers have uncovered a few more errors (always because of symbolic references). I suspect more are lurking, and because we don't have any automated testing it's not likely that we'll find every combination of settings/inputs that cause these errors. That means our customers will find the problems, which is bad.
        I can understand where it would be bad for a customer to find a bug, but IMO it's also bad for that customer NOT to receive an error, and to continue on as if nothing happened when in reality, it is probable that data has been lost, or there has been some other problem with their transaction.
        If you give a man a fish he will eat for a day.
        If you teach a man to fish he will buy an ugly hat.
        If you talk about fish to a starving man, you're a consultant.
Re: turn off strict for production code
by tomhukins (Curate) on Sep 12, 2005 at 15:41 UTC

    Others have suggested using the if pragma. If you prefer to avoid installing anything new, try:

    eval 'use strict' if ($condition);

    Update: As halley points out, this won't work for pragmas, such as strict, only for modules.

      Except that doesn't actually work. It turns on the strict rules for the rest of the string you're evaluating, but that's it.
      % perl use strict; $x = 1; print $x,$/; ^D Global symbol "$x" requires explicit package name at - line 2. Global symbol "$x" requires explicit package name at - line 3. Execution of - aborted due to compilation errors. % perl eval 'use strict' if 1; $x = 1; print $x,$/; ^D 1
      By convention, the all-lowercase modules like strict, warnings, if, and utf8 are pragma declarations. They change the rules of Perl as a language. You should expect that they work through magic, and they produce results which are magical. Typically, they are not just "build up a symbol table and call import()" like all the other modules.

      --
      [ e d @ h a l l e y . c c ]

Log In?
Username:
Password:

What's my password?
Create A New User
Domain Nodelet?
Node Status?
node history
Node Type: perlquestion [id://491277]
Approved by marto
help
Chatterbox?
and the web crawler heard nothing...

How do I use this?Last hourOther CB clients
Other Users?
Others pondering the Monastery: (6)
As of 2024-03-19 09:27 GMT
Sections?
Information?
Find Nodes?
Leftovers?
    Voting Booth?

    No recent polls found