Why not use strict and warnings in Perl?

Question

I\'ve seen obfuscated and golfed code that keeps is off to avoid declaring variables, and I can see skipping them on the command line with the -e switch to keep the one-liner sh

Answer 1

Doing use strict and use warnings helps someone understand exactly what Perl is doing.

Someone who understands exactly what Perl is doing and why, all of the time (i.e., pretty much nobody), would qualify for omitting them in order to save space and possibly execution time. Unfortunately, many of the people who want to save space and time are those who don't know exactly what Perl is doing and why, and their understanding of what Perl is doing is based on so many false assumptions learned from other languages, that they should absolutely never be allowed to omit them.

There are some other valid reasons as well:

• experimenting with behavior that would produce a warning that you are already fully aware of (e.g., a lot of recursion)
• using old packages (although any of my packages written after about July, 2000 still produce no messages with either use strict or use warnings, so "old" here means really, really old, like Perl version 4 or older)
• when you want to take advantage of magical Perl behavior that no one would expect (but which you do expect because you are an expert) and don't want to pay the price of a warning for doing so

By the way, for programs accepting any input and performing actions on the basis of that input, it is also very important to use the -T flag to help track the use of possibly tainted data obtained from user input.

Update: @mob makes a claim in a comment that bears some investigation, i.e., that not using strict and warnings is a micro-optimization below the point of even average insignificant microptimizations. In every case below, the real time for not using strict and warnings is 12 milliseconds, and in every case below, the real time for using them is 57 milliseconds or more.

So there is, just as I said originally, a possible benefit in execution time (that would only matter if you were doing something like embedding Perl scripts within templates and running 10 or 20 of them at a time every time a web page was loaded, for example), but it is still recommended that you use them unless you truly know exactly what Perl is doing and why, all of the time. My description of this category of "experts" is intended to be very close to the empty set. If you think you fall into this category, you automatically don't.

[j@5 ~]$ time perl -e '1;'

real    0m0.012s
user    0m0.005s
sys     0m0.007s
[j@5 ~]$ time perl -e '1;'

real    0m0.012s
user    0m0.010s
sys     0m0.005s
[j@5 ~]$ time perl -e '1;'

real    0m0.012s
user    0m0.011s
sys     0m0.001s
[j@5 ~]$ time perl -e '1;'

real    0m0.012s
user    0m0.004s
sys     0m0.007s
[j@5 ~]$ time perl -e '1;'

real    0m0.012s
user    0m0.005s
sys     0m0.007s
[j@5 ~]$ time perl -e 'use strict; use warnings;'

real    0m0.058s
user    0m0.058s
sys     0m0.000s
[j@5 ~]$ time perl -e 'use strict; use warnings;'

real    0m0.057s
user    0m0.041s
sys     0m0.016s
[j@5 ~]$ time perl -e 'use strict; use warnings;'

real    0m0.057s
user    0m0.033s
sys     0m0.025s
[j@5 ~]$ time perl -e 'use strict; use warnings;'

real    0m0.057s
user    0m0.050s
sys     0m0.009s