Which safety net do you use in Perl?

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

Both, of course. If perl were designed today, use strict and use warnings would be the default behavior. It's just like having warnings turned on in a compiler - why would you not do that by default?

Answer 2

use strict;
#use warnings;
use diagnostics; # "This module extends the terse diagnostics..." by http://perldoc.perl.org/diagnostics.html

Both! But I prefer diagnostics, instead of warnings, which give you some more information.

Answer 3

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.

Answer 4

Use both, as the linked page says.

The documentation is perhaps a bit unclear. use strict and use warnings catch different problems; use strict will not cause your program to immediately exit when mere warnings are encountered, only when you violate the strict syntax requirements. You will still get only warnings printed when your code does things that are less seriously bad.

Answer 5

What you have doesn’t even start to be enough.

I use code approximating this as a starting point. It works well in my environment, although as always your mileage may vary.

#!/usr/bin/env perl

use v5.12;
use utf8;
use strict;
use autodie;
use warnings; 
use warnings    qw< FATAL utf8      >;
use feature     qw< unicode_strings >;
use open        qw< :std  :utf8     >;
use charnames   qw< :full           >;

# These are core modules:
use Carp                qw< carp croak confess cluck >;
use File::Basename      qw< basename        dirname >;
use Unicode::Normalize  qw< NFD NFKD       NFC NFKC >;
use Getopt::Long        qw< GetOptions              >;
use Pod::Usage          qw< pod2usage               >;

our $VERSION = v0.0.1;

$0 = basename($0);  # shorter messages
## $| = 1;

$SIG{__DIE__} = sub {
    confess "Uncaught exception: @_" unless $^S;
};

$SIG{__WARN__} = sub {
    if ($^S) { cluck   "Trapped warning: @_" } 
    else     { confess "Deadly warning: @_"  }
};

END { 
    local $SIG{PIPE} = sub { exit };
    close STDOUT;
}

if (grep /\P{ASCII}/ => @ARGV) {
   @ARGV = map { decode("UTF-8", $_) } @ARGV;
}

binmode(DATA, ":utf8");

## Getopt::Long::Configure qw[ bundling auto_version ];

if (!@ARGV && -t STDIN) {
    print STDERR "$0: reading from stdin: type ^D to end, ^C to kill...\n";
} 

while (<>) {
    $_ = NFD($_);
    # ...
    print NFC($_);
}

exit;

=pod

=encoding utf8

=head1 NAME

=head1 SYNOPSIS

=head1 DESCRIPTION

=head1 OPTIONS

=head1 EXAMPLES

=head1 ERRORS   

=head1 FILES

=head1 ENVIRONMENT

=head1 PROGRAMS

=head1 AUTHOR

=head1 COPYRIGHT AND LICENCE

=head1 REVISION HISTORY

=head1 BUGS

=head1 TODO

=head1 SEE ALSO

=cut

__END__

Your UTF-8 data goes here.

You can find more examples of this sort of thing in action in the Perl Unicode Tool Chest, currently up to around 50 files ranging from the simple to the sublime.