Question

Which safety net do you use?

use warnings;

or

use strict;

I know that

A potential problem caught by use
strict; will cause your code to stop
immediately when it is encountered,
while use warnings; will merely give a
warning (like the command-line switch
-w) and let your code run.

Still I want to know that which one is mostly used by the Perl-programmers. Which one they have seen being used the most?

Answer 1

use strict generates an error if you use symbolic references (ie, strings to represent names of symbols). It generates an error if you use a variable without declaring it (this encourages the use of lexical ‘my‘ variables, but is also satisfied if you properly declare package globals). It also generates an error if you leave barewords hanging around in the script (unquoted strings, essentially, by Perl’s definition of quotes). With ‘strict‘, you may enable or disable any of three categories of strictures, and my do so within scoped blocks. It is a best practice to enable strictures, though on occasion legitimate code requires that some of its features be locally disabled. However, one should think long and hard about whether this is really necessary, and whether their solution is ideal. You can read about strictures in Perl’s POD entitled ‘strict’.

use warnings generates a warning message based on many criteria, which are described in the POD ‘perllexwarn’. These warnings have nothing to do with strictures, but rather, watch for the most common “gotchas” one is likely to encounter in their programming. It is a best practice to use warnings while writing scripts too. In some cases where the message might be undesirable a certain warning category may be locally disabled within a scope. Additional info is described in ‘warnings’.

use diagnostics makes the warnings more verbose, and in a development or learning environment, particularly among newcomers, that’s highly desirable. Diagnostics would probably be left out of a ‘final product’, but while in development they can be a really nice addition to the terse messages normally generated. You can read about diagnostics in the Perl POD “diagnostics.”

There is no reason to force oneself to use only one of the above options or another. In particular, use warnings and use strict should generally both be used in modern Perl programs.

In all cases (except diagnostics, which you’re only using for development anyway), individual strictures or warnings may be lexically disabled. Furthermore, their errors may be trapped with eval{ .... }, with Try::Tiny‘s try/catch blocks, and a few other ways. If there’s a concern about a message giving a potential attacker more information about a script, the messages could be routed to a logfile. If there’s a risk of said logfile consuming lots of space, there’s a bigger issue at hand, and the source of the issue should either be resolved or in some rare cases simply have the message disabled.

Perl programs nowadays should be highly strict/warnings compliant as a best practice.