5.2 Warnings and Strictness

Previous Table of Contents Next

5.2 Warnings and Strictness

Because use strict and use warningstwo examples of pragmas (directives that affect the compilation of a program)are so important in program maintenance, I'm going to give them a more thorough treatment than is common.

It's not hard to see why warnings and strict are vital. Without themwell, watch:

% perl

do you, each reader, accept risks, close calls

and wait until failure

and then; alarm rings and people, listen shocked, horrified

or do you, "use strict" and "use warnings" and sleep soundly;

my main $message; study earnestly while you-can;

do this, cos I, tell you

and you, can be free;



This doggerel not only compiles, it actually runs without error. (Fortunately, it doesn't actually do anything.)

In fact, if you just consider legal compile-time syntax, virtually anything goes:

% perl -c

There was a young man from Maastricht

Whose programs just never had clicked

One day he discovered

The bugs he had smothered

Not using warnings or strict


- syntax OK

Unless you want to program in an environment where poetrybad poetrycan just as easily be legal syntax as your best coding efforts, use warnings and strict in every program.

Of course, using these pragmas is not a substitute for critical and analytical thinking. It is worth understanding exactly what they mean so you can tell what their diagnostics denote and when it is appropriate to suppress them. Until you arrive at that understanding, however, your life will be easier if you enable the pragmas than it will if you don't, even if you don't know what they're doing.

In fact, both warnings and strict are abbreviations for a host of different types of protection, like broad-spectrum antibiotics. Let's look under the hood.

You may be unfamiliar with some of the command-line flags used in this chapter, but they're very useful. Here's a brief overview:

  • -c Compile only. Useful for syntax checking; if you have been making extensive modifications to a program and you know it's bound to have syntax errors, you can find out what they are without risking the program being run. Code in BEGIN or CHECK blocks will be run, because their purpose is to facilitate the compilation of later code during this phase. In particular, this means that code in modules that are used will be run.

  • -e CODE Execute CODE as Perl instead of reading the program from a file. This switch allows you to make "one-liners" of Perl code without having to create a file to put that code in. Very handy for testing constructions you're unsure of and aliasing shell shortcuts so you don't have to create a new file in ~/bin.

  • -MMODULE Equivalent to putting "use MODULE" at the beginning of the code to be executed. To pass arguments to the import() routine, add them after an =. Thus "-Mstrict=subs" is equivalent to "use strict qw(subs)", and "-Mstrict=subs,vars" is equivalent to "use strict qw(subs vars)".

  • -I DIRECTORY Equivalent to "use lib 'DIRECTORY '".

  • -l Automatically append a newline to the arguments of all print (but not printf) statements. This also removes trailing newlines when the -n or -p switches are used to wrap an input loop around code.

For more details on these switches, see the perlrun manual page.

A handy way of executing a few lines of Perl without having to put them in a file is to feed them to the standard input of perl from the command line. I've shown this here by terminating the input with the usual end of input character for UNIX shells, control D (^D). What follows after that point is the output of the program. You can't edit lines you've already entered, so this is of limited use, but I use it often here as a convenient way of demonstrating code.

    Previous Table of Contents Next
    © 2000- NIV