in reply to Use Strict needed?

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.

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

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

Replies are listed 'Best First'.
Re: Use Strict needed?
by Abigail-II (Bishop) on Aug 05, 2002 at 12:53 UTC
    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

[reply]
      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

[reply]
      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.
[reply]
      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 :-)

[reply]
        How much debugging do you expect from a script that has been running fine for 5 months?

        There's little to gain when adding strict now, but there's a lot of debugging time to lose when you add it now.

        Abigail

[reply]

In Section Seekers of Perl Wisdom