Take the 2-minute tour ×

I'm wondering why

use warnings;
use strict;

are not default in Perl. They're needed for every script. If someone (for good reason) needs to disable them, they should use no strict and/or should use some command line argument (for one-liners).

Are there too many badly-written CPAN modules (using "badly" to mean without use strict)? Or is it because this can break a lot of code already in production? I'm sure there is a reason and I would like to know it.

In 5.14 IO::File is loaded automagically on demand, wouldn't it be possible to do something like that with these basic pragmas?

share|improve this question
See also this PerlMonks discussion: Why isn't C<use strict> the default? –  toolic May 18 '11 at 20:16
possible duplicate of Why not use strict and warnings in Perl? –  Jim G. Aug 10 '13 at 2:41
add comment

5 Answers

up vote 43 down vote accepted

It's for backwards compatibility. Perl 4 didn't have strict at all, and there are most likely still scripts out there originally written for Perl 4 that still work fine with Perl 5. Making strict automatic would break those scripts. The situation is even worse for one-liners, many of which don't bother to declare variables. Making one-liners strict by default would break probably millions of shell scripts and Makefiles out there.

It can't be loaded automagically, because it adds restrictions, not features. It's one thing to load IO::File when a method is called on a filehandle. But activating strict unless the code did something prohibited by strict is meaningless.

If a script specifies a minimum version of 5.11.0 or higher (e.g. use 5.012), then strict is turned on automatically. This doesn't enable warnings, but perhaps that will be added in a future version. Also, if you do OO programming in Perl, you should know that using Moose automatically turns on both strict and warnings in that class.

share|improve this answer
add comment

If you are on a modern Perl, say so, you just have to enable it. 5.12 applies strict except for one-liners. It can't be default because of backward compatibility.

$ cat strict-safe?.pl
use 5.012;

$ perl strict-safe\?.pl 
Global symbol "$foo" requires explicit package name at strict-safe?.pl line 2.
Execution of strict-safe?.pl aborted due to compilation errors.
share|improve this answer
add comment

Well, use strict is default now, sort of.

Since Perl 5.12.0 if you require a version of Perl >= 5.12.0, then your script will have all the backwards incompatible features turned on, including strict by default.

use 5.12.0;
use warnings;

Is the same as:

use strict;
use warnings;
use feature ':5.12';

It hasn't been turned on more broadly because doing so would break a lot scripts that people depend on to "just work".

Moose also automatically turns on strict and warnings when you use it. So if you do any Moose based Perl OOP, then you get a free pass here, too.

share|improve this answer
Thank you mentioning Mooose. Nice to know. –  kobame May 19 '11 at 3:45
add comment

It's a philosophical question, not a "it won't work" question.

First, perl has always been under the "you can do it incorrectly if you want" type of paradigm. Which is why there are a lot of perl haters out there. Many would prefer that the language always force you to write good code, but many quick-script-hackers don't want to. Consider:

perl -e '@a = split(/[,:]/, $_); print $a[1],"\n";'

Now, it would be easy to add a 'my' in front of the @a, but for a one line, one-time script people don't want to do that.

Second, yes, I think most of CPAN would indeed need to be rewritten.

There isn't a good answer you'll like, I'm afraid.

share|improve this answer
add comment

You can use the common::sense module, if you need:

use utf8;
use strict qw(vars subs);
use feature qw(say state switch);
no warnings;
use warnings qw(FATAL closed threads internal debugging pack
                portable prototype inplace io pipe unpack malloc
                deprecated glob digit printf layer
                reserved taint closure semicolon);
no warnings qw(exec newline unopened);

It reduces the memory usage.

share|improve this answer
Unfortunately, common::sense isn't very common sense. There are no warnings or strictures that should be turned off by default. –  Ether May 18 '11 at 21:26
common::sense isn't. Its selection of warnings and strictures it fails to turn on reflects the author's quirks, not good practice. In particular, failing to turn on strict references and undefined warnings is asking for trouble. As for the memory usage claim, while strictly true, it is never seen in practice. Once any other sensible module is loaded, strict and warnings will be loaded. In practice, you wind up using a smidge more memory. Finally, the author is not somebody you want to be contacting for support. –  Schwern May 19 '11 at 6:27
@Schwern: It also forgets to turn on unicode_strings. And an explicit warnings list means that you may have forgotten some future ones that don’t exist yet, like package warnings. Lastly, you have to delay fatals till runtime, or the compiler misbehaves on error reporting. –  tchrist May 19 '11 at 11:19
add comment

Your Answer


