Why use strict and warnings?

These two pragmas can automatically identify bugs in your code.

I always use this in my code:

use strict;
use warnings FATAL => 'all';

FATAL makes the code die on warnings, just like strict does.

For additional information, see: Get stricter with use warnings FATAL => 'all';

Also... The strictures, according to Seuss


For starters, use strict; (and to a lesser extent, use warnings;) helps find typos in variable names. Even experienced programmers make such errors. A common case is forgetting to rename an instance of a variable when cleaning up or refactoring code.

Using use strict; use warnings; catches many errors sooner than they would be caught otherwise, which makes it easier to find the root causes of the errors. The root cause might be the need for an error or validation check, and that can happen regardless or programmer skill.

What's good about Perl warnings is that they are rarely spurious, so there's next to no cost to using them.

Related reading: Why use my?


There's a good thread on perlmonks about this question.

The basic reason obviously is that strict and warnings massively help you catch mistakes and aid debugging.


Apparently use strict should (must) be used when you want to force Perl to code properly which could be forcing declarations, being explicit on strings and subs, i.e., barewords or using refs with caution. Note: if there are errors, use strict will abort the execution if used.

While use warnings; will help you find typing mistakes in program like you missed a semicolon, you used 'elseif' and not 'elsif', you are using deprecated syntax or function, whatever like that. Note: use warnings will only provide warnings and continue execution, i.e., it won't abort the execution...

Anyway, it would be better if we go into details, which I am specifying below

From perl.com (my favourite):

use strict 'vars';

which means that you must always declare variables before you use them.

If you don't declare you will probably get an error message for the undeclared variable:

Global symbol "$variablename" requires explicit package name at scriptname.pl line 3

This warning means Perl is not exactly clear about what the scope of the variable is. So you need to be explicit about your variables, which means either declaring them with my, so they are restricted to the current block, or referring to them with their fully qualified name (for ex: $MAIN::variablename).

So, a compile-time error is triggered if you attempt to access a variable that hasn't met at least one of the following criteria:

  • Predefined by Perl itself, such as @ARGV, %ENV, and all the global punctuation variables such as $. Or $_.

  • Declared with our (for a global) or my (for a lexical).

  • Imported from another package. (The use vars pragma fakes up an import, but use our instead.)

  • Fully qualified using its package name and the double-colon package separator.

use strict 'subs';

Consider two programs

# prog 1
   $a = test_value;
   print "First program: ", $a, "\n";
   sub test_value { return "test passed"; }
 Output: First program's result: test_value

# prog 2
   sub test_value { return "test passed"; }
   $a = test_value;
   print "Second program: ", $a, "\n";
 Output: Second program's result: test passed

In both cases we have a test_value() sub and we want to put its result into $a. And yet, when we run the two programs, we get two different results:

In the first program, at the point we get to $a = test_value;, Perl doesn't know of any test_value() sub, and test_value is interpreted as string 'test_value'. In the second program, the definition of test_value() comes before the $a = test_value; line. Perl thinks test_value as sub call.

The technical term for isolated words like test_value that might be subs and might be strings depending on context, by the way, is bareword. Perl's handling of barewords can be confusing, and it can cause bug in program.

The bug is what we encountered in our first program, Remember that Perl won't look forward to find test_value(), so since it hasn't already seen test_value(), it assumes that you want a string. So if you use strict subs;, it will cause this program to die with an error:

Bareword "test_value" not allowed while "strict subs" in use at ./a6-strictsubs.pl line 3.

Solution to this error would be

  1. Use parentheses to make it clear you're calling a sub. If Perl sees $a = test_value();,

  2. Declare your sub before you first use it

    use strict; sub test_value; # Declares that there's a test_value() coming later ... my $a = test_value; # ...so Perl will know this line is okay. ....... sub test_value { return "test_passed"; }

  3. And If you mean to use it as a string, quote it.

So, This stricture makes Perl treat all barewords as syntax errors. A bareword is any bare name or identifier that has no other interpretation forced by context. (Context is often forced by a nearby keyword or token, or by predeclaration of the word in question.) So If you mean to use it as a string, quote it and If you mean to use it as a function call, predeclare it or use parentheses.

Barewords are dangerous because of this unpredictable behavior. use strict; (or use strict 'subs';) makes them predictable, because barewords that might cause strange behavior in the future will make your program die before they can wreak havoc

There's one place where it's OK to use barewords even when you've turned on strict subs: when you are assigning hash keys.

$hash{sample} = 6;   # Same as $hash{'sample'} = 6
%other_hash = ( pie => 'apple' );

Barewords in hash keys are always interpreted as strings, so there is no ambiguity.

use strict 'refs';

This generates a run-time error if you use symbolic references, intentionally or otherwise.

A value that is not a hard reference is then treated as a symbolic reference. That is, the reference is interpreted as a string representing the name of a global variable.

use strict 'refs';

$ref = \$foo;       # Store "real" (hard) reference.
print $$ref;        # Dereferencing is ok.

$ref = "foo";       # Store name of global (package) variable.
print $$ref;        # WRONG, run-time error under strict refs.

use warnings;

This lexically scoped pragma permits flexible control over Perl's built-in warnings, both those emitted by the compiler as well as those from the run-time system.

From perldiag:

So the majority of warning messages from the classifications below, i.e., W, D, and S can be controlled using the warnings pragma.

(W) A warning (optional)
(D) A deprecation (enabled by default)
(S) A severe warning (enabled by default)

I have listed some of warnings messages those occurs often below by classifications. For detailed info on them and others messages, refer to perldiag.

(W) A warning (optional):

Missing argument in %s
Missing argument to -%c
(Did you mean &%s instead?)
(Did you mean "local" instead of "our"?)
(Did you mean $ or @ instead of %?)
'%s' is not a code reference
length() used on %s
Misplaced _ in number

(D) A deprecation (enabled by default):

defined(@array) is deprecated
defined(%hash) is deprecated
Deprecated use of my() in false conditional
$# is no longer supported

(S) A severe warning (enabled by default)

elseif should be elsif
%s found where operator expected
(Missing operator before %s?)
(Missing semicolon on previous line?)
%s never introduced
Operator or semicolon missing before %s
Precedence problem: open %s should be open(%s)
Prototype mismatch: %s vs %s
Warning: Use of "%s" without parentheses is ambiguous
Can't open %s: %s

Tags:

Perl

Recent Posts