in reply to Re: Use Strict needed?
in thread Use Strict needed?

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 :-)

  • Comment on Use strict _encouraged_, but not mandated :-)

Replies are listed 'Best First'.
Re: Use strict _encouraged_, but not mandated :-)
by Abigail-II (Bishop) on Aug 05, 2002 at 13:42 UTC
    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

      Well that all depends -- how often has it been run in the past 5 months? In how many different scenarios? Why is the poster looking at it again after this much time? Are there changes that need to be made? Is it going into heavier use?

      I say again, if the developer didn't expect to see warnings then they are a sign that the developer overlooked something. I don't care if it has been running right for the past 5 months; code that spews warnings when I don't expect it to makes me worry.

      Hmm, I wonder what I will see if I put in use strict... <tappity tap> Yikes! Where are all these warnings coming from?! <thinks> Oh well, if I remove the use strict they go away. <tappity tap... slams head into hole in sand.>
      How much debugging do you expect from a script that has been running fine for 5 months?

      You would be amazed.

      My experience is that the process of adding strict.pm to any lengthy script that doesn't have it already goes quickly (because it is largely mechanical), and generally fixes several bugs. (In particular you find that "has been running fine" often means, "Shit, that caused the problem I was having?") It may or may not fix the one I started out looking for, but if it doesn't then I generally come out with a pretty good picture of how the code works, and my development time on that code will be faster.