use strict: Making Perl Refuse Your Mistakes

Part I · Module 1 · Chapter 1.10 · use strict: Making Perl Refuse Your Mistakes

1. What a Pragma Is

use strict; is a pragma — a line that changes the rules Perl applies to your code rather than doing anything itself. Two properties follow from that, and both matter:

• It acts while compiling. Per Chapter 1.5, a use takes effect during the compile stage, which is how it can change the rules for the rest of the file as Perl reads it.
• It applies from where it appears to the end of its enclosing block. Put it at the top of the file and it governs the whole file — which is why every script in this course starts with it.

So use strict does not check your program at runtime. It makes Perl refuse to compile certain things at all.

2. The Mistake It Exists to Catch

Here is a program with one typo. The variable is $count; line 5 misspells it as $cuont:

use warnings;

my $count = 0;
$cuont = 1;
print "count=$count\n";

Note that use strict is deliberately absent. Run it:

Name "main::cuont" used only once: possible typo at typo.pl line 4.
count=0

Read that carefully, because it is the reason this chapter exists.

• The assignment on line 4 was accepted. Perl created a brand-new variable called $cuont and put 1 in it.
• $count — the one you meant — still holds 0.
• The script printed count=0, which is wrong.
• It exited with status 0, meaning success.

A caller, a scheduled job or a colleague reading the output has no way to know anything went wrong. The program did not crash; it lied. That is strictly worse than failing, because a failure gets investigated and a wrong number gets used.

There was a hint — possible typo — and it came from use warnings, not from strict. Chapter 1.11 covers that pragma. The hint is real but fragile: it only appears because the name happens to be used exactly once, and it is one line among however many others a real run produces.

3. The Same Program, With use strict

Add the one line:

use strict;
use warnings;

my $count = 0;
$cuont = 1;
print "count=$count\n";

Global symbol "$cuont" requires explicit package name (did you forget to declare "my $cuont"?) at typo-strict.pl line 5.
Execution of typo-strict.pl aborted due to compilation errors.

Nothing ran. No count= line appeared, because this is a compile error — the file is not a valid program under these rules, so Perl never reached the run stage. The exit status is 255.

The message is worth decoding, since its wording confuses nearly everyone the first time:

• "Global symbol" means a variable that is not declared in any enclosing scope — Perl is calling it global because that is the only other thing it could be.
• "requires explicit package name" is Perl saying: if you really want a global, you must say so explicitly. That syntax exists and Chapter 12.7 covers it; it is not what you want here.
• "(did you forget to declare my $cuont?)" is the actual advice, and it is correct. You did not forget to declare $cuont — you meant to type $count.

The fix is not to declare $cuont. It is to read the name Perl is complaining about and notice it is not the name you intended.

4. What use strict Actually Forbids

use strict turns on three separate restrictions. One of them is the reason you use it; the other two are worth recognising but not studying yet.

strict vars — the one that matters now. Every variable must be declared, with my as you have been doing since Chapter 1.7. This is what catches the typo, and it works because of scope: Perl can check, while reading the file, whether a name was declared in any enclosing block. Chapter 1.8 showed the same error for a variable used after its block ended, which is the identical mechanism.

strict subs forbids a bare word where Perl cannot tell what you meant. Chapter 1.1 §7 met the consequence of this already, in the message about a filehandle produced by unquoted text.

strict refs forbids using a string as if it were a variable name. It is a real feature of the language, occasionally used deliberately in older code, and you do not need it in Part I.

For now, treat use strict as one decision rather than three. Chapter 12.7 returns to the parts.

5. Why This Is the Most Important Line in the Module

Every other failure in Module 1 announces itself. A missing semicolon stops the program. A missing module stops the program. A die stops the program. You cannot ship them by accident, because they are loud.

The mistake in §2 is the exception: the program runs, produces output, and exits 0. Nothing in the result distinguishes it from a correct run. In a chip-design flow that is the one failure mode that genuinely matters, because the output of one step is the input to the next — a wrong error count becomes a PASS, a PASS becomes a sign-off, and nobody re-examines a step that reported success.

use strict converts that class of mistake into the loud kind. One line, at the top, in every script, with no exceptions while you are learning. It is the cheapest correctness measure in the language.

6. Mistakes and How They Look

Forgetting the pragma in a quick script. The "quick" script is the one most likely to be run once, trusted, and never reviewed. Put the line in first, before anything else.

Declaring the typo instead of fixing it. Perl suggests my $cuont and it is only guessing from what you typed. Read the name in the message; if it is not a name you meant to use, the fix is a spelling correction, not a declaration.

Putting use strict below the code it should govern. It applies from where it appears onward. Below your statements, it governs nothing of interest.

Assuming it checks more than it does. use strict says nothing about whether your values are sensible — a declared variable holding the wrong number passes without comment. That is what Chapter 1.11 is for, and even then neither pragma checks your logic.

7. What You Should Be Able to Say Now

1. A pragma changes the rules Perl applies, and acts while compiling.
2. Without use strict, a misspelled variable name silently creates a new variable; the script can print a wrong answer and exit 0.
3. With use strict, the same typo is a compile error, so nothing runs at all.
4. Global symbol ... requires explicit package name means "this name was never declared" — and the bracketed suggestion is the useful part.
5. The restriction that catches typos is strict vars, and it works because my plus block scope lets Perl check names while reading the file.
6. Put the line at the top of every script; it only governs what comes after it.

8. Exercise

Exercise 1 — run both halves yourself. Create typo.pl from §2 exactly as written, without use strict, and run it. Record the output and the exit status. Then add use strict; as line 1 and run it again. Write one sentence on which of the two you would rather receive from an overnight job, and why.

Exercise 2 — read the message. In the strict version, the message names $cuont. Say what the correct fix is, and why declaring my $cuont would be the wrong response even though Perl appears to suggest it.

Exercise 3 — placement matters. Move use strict; so that it sits after the $cuont = 1; line. Predict whether the program now compiles, then check. Explain the result using the rule from §1.

Exercise 4 — reason about the risk. A colleague argues that use strict is unnecessary because "the tests would catch a typo like that". Using the output from Exercise 1, give the strongest counter-argument in two sentences.

9. Summary

• use strict is a pragma: it changes Perl's rules, acts at compile time, and applies from its position onward.
• Its absence allows a silent wrong answer. A misspelled name becomes a new variable, the real one keeps its old value, and the script exits 0.
• Its presence turns that into a compile error, so no output is produced and nothing can be mistaken for a result.
• Global symbol ... requires explicit package name means undeclared, and the bracketed my suggestion names the variable you actually mis-typed.
• strict vars is the part that matters now; subs and refs are real and can wait.
• This is the module's most consequential single line, because it is the only failure here that can reach a downstream consumer as a plausible number.

Chapter 1.11 covers the pragma that has sat beside it in every script so far — use warnings, which does not refuse anything, but tells you when a value looks wrong.