Beefy Boxes and Bandwidth Generously Provided by pair Networks
Think about Loose Coupling
 
PerlMonks  

When should you not use strict and warnings?

by space_monk (Chaplain)
on Dec 27, 2012 at 12:35 UTC ( #1010513=perlquestion: print w/ replies, xml ) Need Help??
space_monk has asked for the wisdom of the Perl Monks concerning the following question:

Dear Fellow Monks, it's one of those stray days between Christmas and New Year when I have to be in work but cannot do anything due to the code freeze we have for this period. So this question came to mind. :-)

I'd like to invite Perl Monks to elucidate on when use strict; and use warnings; should NOT used.

There are obviously occasions when unwanted error messages and warnings are generated, but as far as I'm concerned you should only turn it off (no strict) for the statements in question, not for the whole script.

What I would like to know is whether there is any occasion when these should not be used for the entire script?

A Monk aims to give answers to those who have none, and to learn from those who know more.

Comment on When should you not use strict and warnings?
Re: When should you not use strict and warnings?
by Anonymous Monk on Dec 27, 2012 at 12:54 UTC
Re: When should you not use strict and warnings?
by BrowserUk (Pope) on Dec 27, 2012 at 13:09 UTC

    The only reason I can think of for turning them off completely is to try and gain a little performance once you've completely debugged the program.

    I tried this a few times in the past and found that it rarely, if ever, made any significant measurable difference.

    Conversely, I almost always found yet another code or algorithmic change that would speed things up; but I always had to re-enable B&D to find bugs introduced by those changes.

    (My) Bottom line, I always turn them on when I start a script, and for the last 8 years or more never even think about turning them off, except for very small scopes.


    With the rise and rise of 'Social' network sites: 'Computers are making people easier to use everyday'
    Examine what is said, not who speaks -- Silence betokens consent -- Love the truth but pardon error.
    "Science is about questioning the status quo. Questioning authority".
    In the absence of evidence, opinion is indistinguishable from prejudice.

      I think Exporter::Lite complained about how use strict slowed down the compile. Of course, it's a tiny module -- for pretty much anything non-tiny, the overhead added by strict is negligible.

      package Exporter::Lite; require 5.004; # Using strict or vars almost doubles our load time. Turn them back # on when debugging. #use strict 'vars'; # we're going to be doing a lot of sym refs #use vars qw($VERSION @EXPORT);

      (My) Bottom line, I always turn them on when I start a script, and for the last 8 years or more never even think about turning them off, except for very small scopes.

      I often forget to turn them on for a brand-new script and then wonder why my script is not working =(

Re: When should you not use strict and warnings?
by Anonymous Monk on Dec 27, 2012 at 13:25 UTC
    Well, how much do you value your hair-follicles, your forehead, and yonder wall?
Re: When should you not use strict and warnings?
by LanX (Canon) on Dec 27, 2012 at 13:37 UTC
    Well ... a friend of mine was fired after introducing strict in an old script... :(

    Cheers Rolf

      Without testing? In production? Ewwww. Or was it due to the number of 'bugs that now need to be fixed'?

      --MidLifeXis

      Clearly an instance of killing the messenger that brings bad news.

      CountZero

      A program should be light and agile, its subroutines connected like a string of pearls. The spirit and intent of the program should be retained throughout. There should be neither too little or too much, neither needless loops nor useless variables, neither lack of structure nor overwhelming rigidity." - The Tao of Programming, 4.1 - Geoffrey James

      My blog: Imperial Deltronics
      I hope he's glad he got the hell out of thatplace before a production failure that they never even cared to look-for was blamed on him. I've certainly seen good people get canned for that ... and they dusted the soles of their shoes as they departed.
Re: When should you not use strict and warnings?
by Tommy (Chaplain) on Dec 27, 2012 at 14:20 UTC

    Far be it from me to discourage the use of warnings and strict. It's extremely disheartening to read in one of the responses from LanX that someone was ever fired for using them.

    As you've pointed out, one aspect of this that I've found useful resorted to in very rare cases was to switch off warnings in only a certain part of a program in an enclosing block. This was almost always because of the "uninitialized" warning sounding off when it was irrelevant. I recall reading some CPAN code recently where the "once" warning was bothering a certain Matt Trout. (See the colorful language on line 95 of Moo.pm v 1.000007)

    As for me, I can't think of a time when it would ever be apropos to disable strict or warnings completely.

    --
    Tommy
    $ perl -MMIME::Base64 -e 'print decode_base64 "YWNlQHRvbW15YnV0bGVyLm1lCg=="'
Re: When should you not use strict and warnings?
by BillKSmith (Chaplain) on Dec 27, 2012 at 14:30 UTC
    "My script ony seems to work without them." is not a good reason to omit them. Find and fix the problem.
    Bill
Re: When should you not use strict and warnings?
by CountZero (Bishop) on Dec 27, 2012 at 16:04 UTC
    I never switch off use strict but I used to disable use warnings for production code (but only after it ran clean of course).

    Nowadays I always use Modern::Perl with enables both strict and warnings and I do not bother with disabling it anymore in production code. In rare cases I might locally disable irrelevant but well understood warnings for unititalized variables.

    I use Perl mainly for transforming data from one format to another and when an unexpected "unitialized variable" warning crops up, it ususally means that there is something wrong with the data and the parser I wrote has failed to match some data to a variable, hence the warning. I think this warning is a nice last resort catch-all line of defence and I would not want to miss it.

    CountZero

    A program should be light and agile, its subroutines connected like a string of pearls. The spirit and intent of the program should be retained throughout. There should be neither too little or too much, neither needless loops nor useless variables, neither lack of structure nor overwhelming rigidity." - The Tao of Programming, 4.1 - Geoffrey James

    My blog: Imperial Deltronics
Re: When should you not use strict and warnings?
by Arunbear (Parson) on Dec 27, 2012 at 17:06 UTC
    When the entire script fits on one line? ;)
    % cat nums 1 2 3 4 % perl -nE '$sum += $_; END { say $sum }' nums 10

      Well, adding -Mstrict and qualifying every variable with my may be a little much for a one-liner. But adding a single -w? Consider:

      2:05 >type nums.txt 1 2 3 4 2:05 >perl -nE "$sum += $_; END { say $sum }" nums.txt 10 2:06 >perl -nwE "$sum += $_; END { say $sum }" nums.txt 10 2:06 >perl -nE "$sum += $_; END { say $sun }" nums.txt 2:06 >perl -nwE "$sum += $_; END { say $sun }" nums.txt Name "main::sum" used only once: possible typo at -e line 1. Name "main::sun" used only once: possible typo at -e line 1. Use of uninitialized value $sun in say at -e line 1, <> line 4. 2:06 >

      That’s a lot of potential help for the cost of just one extra character on the command line. :-)

      Athanasius <°(((><contra mundum Iustus alius egestas vitae, eros Piratica,

Re: When should you not use strict and warnings?
by Old_Gray_Bear (Bishop) on Dec 27, 2012 at 17:51 UTC
    On anything other than one-liners, I never turn off strictures.

    I can count the number of times I have had to turn off strictures for production code in the past seventeen years on the thumbs of one hand. (An ugly piece of CGI code where we couldn't trust the database to reliably hand us back a ' ' when it encountered a NULL in a table.)

    On the other hand, the number of times I have been pulled into a bug-hunt ("I only changed these two lines and now the code doesn't work. We can't put this back into production with out this bug-fix. And It's gotta be in place before we run the trial-balance at 0030!") only to look at the top of the code and say "put in use strict; use warnings; right here and lets see what falls out." Followed by the discovery of the typo in the fix. You have to love Corporate 'Coding' Standards that require all variable names to be at least eleven characters long and less than 255, CamelCased (with exceptions for certain 'common' words) and inflected....

    If I remember correctly, strict is only involved with the Perl compile phase, so you can't take a performance hit there; warnings has both compile- and run-time component. But the few times that I have bench marked codes with and without, the extra run-time was well below the noise threshold.

    We had this do-everything-in-a-single-wait/process/wait-loop program that had grown by accretion over five years, and now the performance was unacceptable in a Web server environment. And no, there wasn't time or budget for more that a couple of weeks to work on it; a rewrite was right out. We got the biggest-bang-for-the-buck out of unrolling a pair of for loops and implementing a dispatch table instead of a cascade of if/then/elsif statements. All other sources of 'extra' CPU were swamped by the 7% performance boost we got from the Duff's Device analysis and the 11% boost from the dispatch table. (Y(M|K)MV)

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

    OGB

Re: When should you not use strict and warnings?
by blue_cowdawg (Monsignor) on Dec 28, 2012 at 23:44 UTC
        I'd like to invite Perl Monks to elucidate on when use strict; and use warnings; should NOT used.

    Here at the Blue Cowdawg Perl Coding Ranch not using strict and warnings is considered a hanging offense.

    I cannot think of any reason why I would not use them, even in a production environment. When Operations calls me at oh-dark-hundred to tell me that something isn't working the first thing I'm going to do is check logs to see if the script has puked up anything. While strict and warnings are particularly useful for catching compile time issues, warnings in particular can catch other issues. Such as? Let me paint a vignette for you:

    Global Operations: The FTP push for Acme Plumbing and Booby Traps LLC has stopped working. The customer is complaining that he hasn't seen reports since ten hours ago.
    Me: Hang on a sec... clikety clickety clickety OH! The customer file store isn't mounted any more... clickety! click! Should be good to go now.

    While that's a bad example of why warnings helped out, the problem was located when the logs were checked and the opendir call failed and was noted. (I don't use die in my production code I have my own function that does the same thing, but logs to a file instead of stdout/stderr) </p.

    A better example of how warnings helped would be in a CGI that had multiple hands involved. A module that my code depended on was modified by its author. The return values from that module's methods (subs) had changed and the author neglected to warn anybody. My code (via warnings) started complaining about uninitialized values which were duly logged in the Apache logs.


    Peter L. Berghold -- Unix Professional
    Peter -at- Berghold -dot- Net; AOL IM redcowdawg Yahoo IM: blue_cowdawg
      But smoking crack is fine?

        just turn your humor circuit on. :-)


        Peter L. Berghold -- Unix Professional
        Peter -at- Berghold -dot- Net; AOL IM redcowdawg Yahoo IM: blue_cowdawg

Log In?
Username:
Password:

What's my password?
Create A New User
Node Status?
node history
Node Type: perlquestion [id://1010513]
Approved by ww
Front-paged by Tommy
help
Chatterbox?
and the web crawler heard nothing...

How do I use this? | Other CB clients
Other Users?
Others chilling in the Monastery: (7)
As of 2014-12-19 02:24 GMT
Sections?
Information?
Find Nodes?
Leftovers?
    Voting Booth?

    Is guessing a good strategy for surviving in the IT business?





    Results (70 votes), past polls