Chip Salzenberg: on time in a way you couldn't possibly understand

April 29, 2011

Retrofitting Enlightened Perl: Part 1 of N

At Topsy we started developing our code base before the Perl Enlightenment reached us. So there is quite a bit of modernization to do. Fortunately, this is (1) relatively easy to automate and (2) fun. I'll be writing about this process as it proceeds.

First steps in reforming an old code base involve janitorial duties: (1) Fixing any actually bad things that have crept in; and (2) Trimming out unused code (no use in renovating a room you never use).

In our case, the old bad code includes some classics:

Lack of "use strict". Yeah, I know, I don't get it either.

Lack of "use warnings". Not as big a deal, but still not acceptable.

Use of "perl -s".

Now "perl -s" isn't as evil as you might imagine, in context. Sure, it turns any command line option into an assignment to a global variable. And if the code were being packaged for someone else, that would be awful. For internal use, this hack's functionality is not an issue. However, usability is still an issue. If I misspell a command line option it's just impolite not to tell me about it. Getopt::Long is my argument parser of choice; so far I haven't seen any compelling improvements on it.

But back to strict/warnings. You might think that the first step is adding "use strict" and "use warnings" to all our Perl code. But under the assumption that there will be more standard modules to load (sneak preview: "mro" and "Method::Signatures"), the first step is actually to create an "Std.pm" module that does all the, well, standard things. One can use ToolSet to to do this, but as always, TMTOWTDI. And of course if it weren't automated we wouldn't be properly Lazy. More on this tomorrow.