Had you asked the same question about starting to use "-w" instead of "use strict", I had suggested to ignore the warnings and disable -w again. After all, if you script runs without problems, let it, and use of uninitialized values could just mean that Perls default is working for you.

But if you get these warnings because of "use strict", you might have some deep and dark errors hidden in the bowels of you script. I'd worry if I were you.

In general, it's a good idea to use "use strict" and "-w", as it well help you while you are developping your script. But there's not much to gain to add them to an existing script that has proven to run without problems.

Unless you plan to modify it. But "use strict" is lexically scoped, and "use warnings" is lexically scoped too.

Abigail

Thank you for all your comments.

See, the thing is that without use strict you can't be sure that _all_ of your variables are declared. You may have missed one or two.

In my opinion any program that I'm going to use for doing "real" work will always have use strict and use warnings in it. And I always put them in from the start for precisely the reason that you're seeing - it's far harder to retrofit them later.

Of course, it's up to you (or, I guess, your manager) as to whether you're going to insist on making all of your code run cleanly under strict and warnings, but I know I'd feel uneasy having them turned off in any production code.

Of course, you can make it easier for yourself to do the clean-up in sections by making judicious use of the no strict and no warnings pragmas.

"The first rule of Perl club is you do not talk about Perl club."
-- Chip Salzenberg

See, the thing is that without use strict you can't be sure that _all_ of your variables are declared. You may have missed one or two.

Yes, and? Is that a bad thing for a script has been working for some time already? "use strict" is a tool, not an end to it self. And it isn't a magic wand that will create correct programs for you.

Abigail

See, the thing is that without use strict you can't be sure that _all_ of your variables are declared. You may have missed one or two.

Yes, and? Is that a bad thing for a script has been working for some time already?

Well that all depends on how well the program has been tested. Just because it's been running successfully for some time, that doesn't mean that it's been down every possible execution path. There could be a big bug ready to bite you on the very next run.

And I'm not saying that use strict will necessarily find that bug. But it's one tool that is great for preventing some particular classes of bugs.

"use strict" is a tool, not an end to it self. And it isn't a magic wand that will create correct programs for you.

You're absolutely right. And I hope I never gave the impression that I thought otherwise.

--
<http://www.dave.org.uk>

"The first rule of Perl club is you do not talk about Perl club."
-- Chip Salzenberg

Yes it is a "bad thing". If it is a warning you expected, then things are probably okay. However in this case it seems that the individual was not expecting warnings, and so I would worry. Code that spews unexpected warnings, but seems to work anyway... Yikes! Just removing warnings and putting it back into place is like burying your head in the sand and hoping that all those flashing lights don't mean anything.

True, but OTOH, it can save you a lot of work when you:
a) Treat variables as though they have values in them, but they are not initialised
OR
b) Use the wrong form of a variable (@list, $list, %list -- especially easy when you a referring to specific items in a list/hash, i.e. preceeded by $)

I would say you are better off leaving strict _on_, unless you have a good reason to turn it off. Otherwise, you can easily spend considerable time debugging something that strict would have warned you about straight up. It's not a magic wand, but it is a nice solid fence that protects you from lack-of-caffeine errors :-)

... and if you're anything like me, in a large listing, there always seems to be something that you forget. a simple 'use strict' can take care of that in many places. For example, it might, for our example, tell us that we used an unititilized value at line xyz. Going to xyz we realize we need to change something.

Or you may realize something that might be wrong (or that could be improved) with your current implementation.

From my (exceedingly short, I admit) experience, use strict has saved me a lot of time.

I recommend (if this didn't convince you) doing a seach with terms strict, use strict, and/or strict.pm. You'll find quite a bit of good discussion about the issue.