use strict; # always use warnings;# usually
Why not always? I would make it:
use strict; # always use warnings; # always
and also use the taint mode:
#!/usr/bin/perl -T
in CGI scripts (or any other scripts invoked by someone else than the system user they run as) always as well.
I would personally suggest to always use warnings, even stronger than stricture. Here's my reasoning:
Both strict and warnings pragmas (or pragmata if you're into Perligata) are lexically scoped. If "use strict" gives you some error (or "use warnings" gives you a warning) which you understand (see: perldoc perldiag) and you know what you are doing, then turn it off for the particular part of code you need.
For example, if you have some data in a $row variable, which you are sure that has a number in the first pipe-delimited column (because you generated it yourself or verified already) and you want to have this number incremented and stored in a variable $num, adding one to your $row does the trick:
#!/usr/bin/perl -T
use strict; use warnings;
my $row = "10 | ABC"; my $num = $row + 1; print "$num\n";
__END__
but it prints:
Argument "10 | ABC" isn't numeric in addition (+) at ./lexsnw-rfl1 line 7. 11
The 11 on stdout is OK, but there is also a warning on stderr. Let's see what does it mean in perldoc perldiag:
Argument "%s" isn't numeric%s
(W numeric) The indicated string was fed as an argu-
ment to an operator that expected a numeric value
instead. If you're fortunate the message will iden-
tify which operator was so unfortunate.The "(W numeric)" means it's an optional warning of the "numeric" category, which we can find in Category Hierarchy of perldoc perllexwarn.
Now, when we know that this particular warning, even if usually very helpful, is not needed this time, we can turn it off:
#!/usr/bin/perl -T
use strict; use warnings;
my $row = "10 | ABC";
my $num;
{
no warnings 'numeric';
$num = $row + 1;
}
print "$num\n";__END__
Of course this is only an example. It doesn't make sense to turn a warning off if that means writing more code than rewriting it in a way which doesn't produce any warnings in the first place. Similarly, it doesn't make much sense to turn the warnings on in a three line program, only to have the only possible warning turned off. It can, however, make sense in a larger program or module, especially while doing tricks which are impossible with strict or always produce warnings.
Here's another, equally bad example:
#!/usr/bin/perl -T
use strict; use warnings;
my $varname = 'var';
{
no strict 'refs';
$$varname = 10;
}# ...still strict with warnings here...
{
no strict 'vars';
no warnings 'once';
print "$var\n";
}# ...still strict with warnings here...
__END__
The points is that in my opinion you should never turn off any warning you don't understand and you should never do anything which gives you a warning or is an error with strict, unless you exactly know what you are doing.
When I talk to beginners I always say: "Always use strict and warnings" with the silent "unless you exactly know what you are doing" implied (as with any sentence starting with "Always"), because if they exactly know what they are doing, they also know how to lexically ignore particular warnings and strictures, and I wouldn't call them beginners in the first place.
Sorry for a long and off-topic post, but I just wanted to say that there is absolutely nothing which would be impossible to do with:
use strict; use warnings;
in the beginning. You can always work around warnings and strictures if that is really what you want, but it's useful to be explicit in those cases, unless we're talking about one-liners or little scripts where being too explicit would make them less clear.
-- ZSDC Perl and Systems Security Consulting
-- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] <http://learn.perl.org/> <http://learn.perl.org/first-response>
