use strict;
use warnings;
[download]

are often missing from programs that I see.

Careful you can get shot down in flames for that sort of talk.

Understanding why warnings and strict are good, and why they shouldn't be necessary in deployed code is something all new Perl programmers should learn. Unfortunately not all trainers and/or Perl gurus agree with that statement.

~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Barbie
Birmingham Perl Mongers
Web Site: http://birmingham.pm.org/
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

Actually ... chanting:

use strict;
use warnings;
[download]

in this community earns elevation via XP. But you do raise very good points, and seeing that you have been programming longer than myself, i realize that you are speaking straight from the "real world" gut. However, i would change "something all new Perl programmers should learn" to "something all new Perl programmers will eventually have to deal with". (as i didn't with one nameless company - instead i left.)

The difference is that i would rather see advice to use strict and warnings than not. The fact that this doesn't happen as often as it should in the real world (let's face it - software design is hard!) doesn't mean that a new Perl programmer shouldn't excercise good practices now before they become ... tainted. Teach 'em the rules now, let 'em break the rules after the learn them. And Perl is all about breaking rules. ;)

Besides, not all companies suffer from the "don't look back" syndrom that seems to accompany leaving strict and warnings out of production code ... i happened to work for two that used strict and warnings in production, as well as CVS religiously and Use Cases regularly. Maybe this wasn't necessary, but we didn't waste time tracking down and fixing obscure bugs either. ;)

UPDATE:
I should mention that the one place i don't use strict and warnings is when i write one-liners. My logic is that one-liners are true throw away scripts, and if you need strict and warnings, then it probably shouldn't be a one-liner.

perl -MCGI=foo -le"print foo{bar=>baz}=>qux"
[download]

jeffa

L-LL-L--L-LL-L--L-LL-L--
-R--R-RR-R--R-RR-R--R-RR
B--B--B--B--B--B--B--B--
H---H---H---H---H---H---
(the triplet paradiddle with high-hat)

Teach 'em the rules now, let 'em break the rules after the learn them

That was my point on particular mailing list. There are far too many new programmers, not just in Perl, that have never been taught good programming. In Perl scripts using warnings and strict helps you in learning some good Perl programming practices.

When writing C programs, I always used 'lint' before compiling and to me warnings and strict are the equivalent. It has taken time, but most Perl programmers I've worked with have gotten used to adding -w/use strict without thinking. In a company I used to work for, they had to port a badly written application to mod_perl. It took several months. The app that I was working on took a couple of weeks to be mod_perl compliant. They have since seen the light :)

Another thing every Perl programmer should be taught is Testing. Its amazing how often the Test:: modules can keep you sane, when all else is driving you nuts with fustration.

~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Barbie
Birmingham Perl Mongers
Web Site: http://birmingham.pm.org/
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

You make a good point. However, when I see code without a single my statement I know strict and warnings have not been used.

Neil Watson
watson-wilson.ca

Removing strict/warnings from deployed code ... I'm of two minds on this one. On the one hand, if it's deployed, you should be able to trust it. (I am, of course, speaking mostly tongue-in-cheek.)

But, warnings and strict, coupled with good logging, will catch a ton of run-time errors, like undefined objects being used and the like.

(Though, good programming practices and code reviews will catch 99% of those, anyways. I can't believe the amount of code that's just slapped together, especially in Perl. At my current position, I'm having to rewrite my customers' code cause my systems can't depend on their dreck.)

------
We are the carpenters and bricklayers of the Information Age.

Don't go borrowing trouble. For programmers, this means Worry only about what you need to implement.

Please remember that I'm crufty and crochety. All opinions are purely mine and all code is untested, unless otherwise specified.

use strict;
use warnings;
no warnings 'uninitialized';
[download]

if (defined $foo and $foo) { ...
[download]

Update on Jun 05, 2003: I do not remember the last time I got a "Variable is used once" warning. Maybe I was just lucky :-)

Jenda
Always code as if the guy who ends up maintaining your code will be a violent psychopath who knows where you live.
   -- Rick Osborne

Edit by castaway: Closed small tag in signature

For me, it's:

use strict;
use warnings;
no warnings 'once';
[download]

because that sodding warning has never caught anything for me that strict wouldn't have trapped sooner. The kicker is that fixing it requires jumping through very silly hoops to make it go away. ($foo = $foo = 1; anyone?) As for uninitialized - well, I don't get a warning on

if ($foo) { ... }
[download]

I admit it's sometimes a little awkward to code around the uninitialized warning, but usually something like adding a || 0 or || '' or such does the trick just fine. And that kind of thing isn't silly, in fact I think it's clearer in intent in that I document via code that I explicitly expect undefs there.

Makeshifts last the longest.

no warnings 'once'; because that sodding warning has never caught anything for me that strict wouldn't have trapped sooner. The kicker is that fixing it requires jumping through very silly hoops to make it go away.

I find that error message very useful. It's not just catching spelling errors, which strict does indeed do better, but it's also catching variables that you really did use once. Variables used once are useless.

If you have a variable that is used only once, then why use that variable? You're throwing away its value if it has one, and there's a variable declared that you don't use. "Variable used only once" actually means "Hey, you forgot to remove a line during your lastmost recent refactoring" or at least "You're throwing away valuable resources". :)

Juerd # { site => 'juerd.nl', plp_site => 'plp.juerd.nl', do_not_use => 'spamtrap' }