|
Re: When should you not use strict and warnings?
by BrowserUk (Patriarch) 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.
| [reply] |
|
|
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 =( | [reply]
[d/l]
[select] |
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
| [reply]
[d/l]
[select] |
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
| [reply]
[d/l]
[select] |
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=="'
| [reply]
[d/l] |
Re: When should you not use strict and warnings?
by Anonymous Monk on Dec 27, 2012 at 12:54 UTC
|
| [reply]
[d/l]
[select] |
Re: When should you not use strict and warnings?
by LanX (Saint) on Dec 27, 2012 at 13:37 UTC
|
Well ... a friend of mine was fired after introducing strict in an old script... :(
| [reply] |
|
|
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
| [reply] |
|
|
| [reply] |
|
|
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.
| [reply] |
Re: When should you not use strict and warnings?
by Arunbear (Prior) 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
| [reply]
[d/l] |
|
|
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. :-)
| [reply]
[d/l] |
Re: When should you not use strict and warnings?
by BillKSmith (Monsignor) 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.
| [reply] |
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? | [reply] |
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
| [reply]
[d/l]
[select] |
|
|
But smoking crack is fine?
| [reply] |
|
|
| [reply] |
|
|