I've been there. But I recommend a somewhat different path:

• Add use strict;
• Write a one-liner that takes all of the resulting error messages and converts them into one massive, insanely ugly our ($x, $Time, @Names, $CurrentId, ...); statement and paste it into the top of the code.
• Add lexical blocks beginning with no strict 'refs' around the remaining problem spots.
• Go make the changes you needed to make in the first place.
• Whenever you get stuck on a problem, convince yourself that it's somehow caused by reusing variables or some other idiocy that use strict would detect if you hadn't added that monstrosity to the top of the file.

As a result, whenever you get frustrated from struggling endlessly with a nasty problem, you'll waste half an hour or so eliminating those awful global variables. Eventually, you'll get to the point where you're more sick of cleaning up that crap than you were sick of chasing after the original problem, and you'll go fix it. Over time, all those globals will gradually disappear.

The bad side of this is that cleaning out the global variables will never fix the problem you're facing at the moment.

The good side of this is that you'll discover and repair dozens of potential problems, and actual problems that people have learned to live with or assumed were intentional (albeit stupid) design decisions.

The so-so side of this is that once you've made everything properly strict-safe, you'll realize that your new version really isn't substantially better than the original. The mindset that produced that many stricture violations is unlikely to have done a great job with the other parts of the system. But you will have a good understanding of what those problems truly are, much better than the initial knee-jerk reaction of disgust that you started out with. And that will enable you to start intelligently refactoring pieces without breaking the overall script (or needing to introduce so many adapters and bandaids that your "improved" version won't be.)

At the risk of offending the fanatical refactoring devotees, I will also assert that even if you manage to refactor the crap out of the code, it's never going to be pretty. It is possible to turn a chicken into a horse by changing one piece at a time, but any sane programmer will start by throwing out the gizzard. As a result, he'll end up with a two meter tall winged herbivore that sleeps standing on one foot and outruns a greyhound -- but dies of starvation. Doing it right requires designing pretty much the whole horse in advance, and if you're going to do that, it'd be less work to just build the damn horse.

But if you do, you won't have time to feed the chicken.

---

---

Posts are HTML formatted. Put <p> </p> tags around your paragraphs. Put <code> </code> tags around your code and data!

Titles consisting of a single word are discouraged, and in most cases are disallowed outright.

Read Where should I post X? if you're not absolutely sure you're posting in the right place.

Please read these before you post! —

• How do I compose an effective node title?
• How do I post a question effectively?
• Markup in the Monastery

Posts may use any of the Perl Monks Approved HTML tags:

a, abbr, b, big, blockquote, br, caption, center, col, colgroup, dd, del, details, div, dl, dt, em, font, h1, h2, h3, h4, h5, h6, hr, i, ins, li, ol, p, pre, readmore, small, span, spoiler, strike, strong, sub, summary, sup, table, tbody, td, tfoot, th, thead, tr, tt, u, ul, wbr

You may need to use entities for some characters, as follows. (Exception: Within code tags, you can put the characters literally.)

	For:		Use:
	&		&
	<		&lt;
	>		&gt;
	[		&#91;
	]		&#93;

Link using PerlMonks shortcuts! What shortcuts can I use for linking?

See Writeup Formatting Tips and other pages linked from there for more info.