Is it necessary to use warnings when already use strict?

Question

Code as follows:

use strict;
use warnings;

Is use warnings; necessary here?

Answer 1

Yes, it's necessary.

use strict and use warnings do different things.

From the strict module's manpage:

strict − Perl pragma to restrict unsafe constructs

From perlrun (for -w ):

prints warnings about dubious constructs, such as variable names that are mentioned only once and scalar variables that are used before being set, redefined subroutines, references to undefined filehandles or filehandles opened read-only that you are attempting to write on, values used as a number that don't look like numbers, using an array as though it were a scalar, if your subroutines recurse more than 100 deep, and innumerable other things.

Answer 2

Yes. strict guards against a very limited number of things. warnings alerts you to a different and much wider set of problems.

Answer 3

This same question came up a few days ago here: Which safety net do you use in Perl? . That link leads to a discussion of strict, warnings, diagnostics, and other similar topics.

Answer 4

Yes, consider:

perl -le "use strict; my $f; my $z = $f*1"

strict doesn't let you know that $f is undefined, while adding warnings will:

perl -le "use strict; use warnings; my $f; my $z = $f*1"
Use of uninitialized value $f in multiplication (*) at -e line 1.

thus the advice to enable both.

Answer 5

It's not necessary in the actual meaning of that word. That is, a program doesn't require it to operate. People often forget what necessary means.

However, if your question is "Does strict enable warnings?", the answer is no. You can see what strict does by reading its documentation .

warnings are often useful in pointing out problems that you should fix. However, Perl's warnings don't require you to fix them, so your program can continue even though it emits warnings.

Some people will tell you to always use warnings, but they make that sort of rule so they don't have to think about it or explain it to people who won't think about it. It's an unpopular position to say anything other than "always use warnings".

warnings are a tool for developers, and if the people who see the warnings aren't going to know what they are or what to do about them, they are probably just going to cause annoyance or confusion. I've seen a few instances where new perls started to emit new warnings for programs, which then filled up disks as no one was monitoring the log files.

I have a much more nuanced rule "use warnings when you'll do something about them, and don't use them if you won't".

I don't even go as far as saying as "Always write warning-free code". There's plenty of code that I write that I will run exactly once, or from the command line, or in other situations where I don't care about the sloppiness. I don't like giving warning-dirty code to other people, but I don't obsess over it for little things I do for myself.

Answer 6

"What do you mean by necessary?" is my reply.

If you think strict and warnings are the same thing, you are wrong. Other people here have given very good answers as to each pragma does.

use warnings will in general make you a better coder. If learning is important, then my answer would be "Yes."

It will also help you avoid bugs, make your errors easier to understand.

In general, I would say that there are very few times when it is warranted to not use both strict and warnings . I even use warnings in my one-liners, eg > perl -we 'print "Hello world!"'

It takes a few seconds to type in, but will save you hours of needless work debugging.