Rehabilitating bad Perl code

Do you have a question? Post it now! No Registration Necessary.  Now with pictures!

Threaded View
I have inherited some code which has uses several horrible constructs,
such as splicing together completely unrelated assignments and
statements with commas, like

   $foo = 1, $bar = 2, print "This is horrid\n";

and into the bargain has been written without strictures, and no "my"

It would be quite nice to find a majority of these automatically; in the
past I've written bits of code (some Perl, also awk and so forth) to
find things like this but it didn't work terribly well, and there's
inches thick of this stuff.  Does anyone have any experience I could
draw on?

I'm thinking about parsing the output from B::Xref; that would at least
give me a list of the variables, and I could then generate a bunch of
"my" statements up near the top.  Any other avenues to explore?


Henry Law            Manchester, England

Re: Rehabilitating bad Perl code

Quoted text here. Click to load it

I would recommend attacking it in pieces: every time you find you need
to change a section of the code, clean up that section, pull the
important functionality out into subs, and move those subs into either a
separate file or a separate section of the same file which is under
'strict' and 'warnings'. Trying to rewrite the whole lot in one go is
likely to produce subtle errors, especially since I don't imagine you
have any sort of test suite.

Once you get to the point where a decent proportion of the code is
clean, you can start working the other way round: take a nasty section,
put it in a sub, and turn off 'strict' and 'warnings' inside that sub.
Once you've got that working you can come back and clean up the subs one
by one, fixing strict errors and other nastiness and replacing globals
with passed-in parameters.

Quoted text here. Click to load it

That sounds like a lot of work for only rather marginal benefit. While
file-scoped lexicals are a little safer than undeclared globals, the
real problem with globals of any kind is that they make data-flow
analysis extremely difficult. In a single-file program there is no
difference between a file-scoped lexical and a package global from this
point of view.

Also, to get any benefit from this, you would have to turn on 'strict';
this does more than just requiring you to declare your variables. You
would have to go through the whole program fixing strict errors, and
doing it in a single pass like that you are much more likely to make a
mistake than if you do it a piece at a time, making sure you've properly
understood each piece before you rewrite it.

Basically, if it ain't broke, don't fix it; if it is broke, take the
opportunity to fix the clarity problems at the same time.


Re: Rehabilitating bad Perl code

On 08/01/13 22:21, Ben Morrow wrote:
Quoted text here. Click to load it

No, you're right.  I have to fight against the impulse to say "Aaaagh;
this is terrible -- I cannot leave this as it is!"

The major problem is that the code does what it's supposed to do right
now (at least I believe it does), and regression tests aren't easy to do.

Quoted text here. Click to load it

Sheesh; yes, I see what you mean.  One does begin to wonder whether it
mightn't be easier to rewrite the damn thing from scratch .. (don't take
that seriously)

Quoted text here. Click to load it

Sage, if unwelcome, advice.  Thank you for a very full reply.


Henry Law            Manchester, England

Re: Rehabilitating bad Perl code

Ben Morrow (for it is he) wrote:

Quoted text here. Click to load it

There's always

use strict "vars";

 < (AIM:troffasky) (
 10:55:13 up 23 days, 13:27,  9 users,  load average: 0.96, 0.77, 0.73
 Qua illic est reprehendit, illic est a vindicatum

Re: Rehabilitating bad Perl code

On Tuesday, January 8, 2013 2:37:57 PM UTC-5, Henry Law wrote:
Quoted text here. Click to load it

Indeed! I inherited several inches of Perl code (literally, the author died=
 very suddenly) that two of us spent several weeks reading - to little avai=

My partner took another position, and I rewrote the whole damn thing (and y=
es, the profanity is justified.)

1. We rewrote the network part in Java, which as it turned out a wise decis=
ion as the applications we interfaced with were Java and we benefited from =
the available classes.
2. We modularized the code, my first big experience in reducing a large cod=
e base to modules, which has benefited me since.
3. I intentionally attempted to rewrite the code in a functional style, whi=
ch has paid for itself in decreased maintenance time over the years.
4. Since I wrote the code, I know it inside out, which I would not have lea=
rned nearly as well simply by reading code someone else has written.
5. Having a negative example, I tried my best to use best practices, which =
taught me some good lessons.

My approach at least in the beginning was to write functions which accepted=
 parameters and returned results using lexical variables as much as possibl=
e, and commented out the existing code. Often this exposed global variables=
, some of these literally a couple of KLOC away from the use of the global.=
 Getting a handle on the globals really allowed me to increase the pace of =
my rewriting effort.

My best advice is not to look on this as a negative, but as a positive. You=
 will be much better off seeing this as an opportunity to do good rather th=
an as a burden to carry.


Re: Rehabilitating bad Perl code

Quoted text here. Click to load it

[very late followup, this]

For education of us all, please say a bit about how you
wrote perl code in a functional style.

Not a whole tutorial, but maybe a few short examples,
maybe even before-and-after versions?



Re: Rehabilitating bad Perl code (David Combs) writes:
Quoted text here. Click to load it

Judgeing from the text, I think what he meant is structuring the code
into named subroutines solving subproblems instead of the usual "5000
lines down the road, there comes the final bracket of 'the loop'" (cf
"Real programmers don't use Pascal").

Re: Rehabilitating bad Perl code

On Wednesday, February 27, 2013 9:19:34 PM UTC-5, David Combs wrote:

Quoted text here. Click to load it

I should have said 'procedural style', by which I mean named blocks of code that
accept arguments and return results.

I would recommend 'Higher Order Perl' which is available as a free web version,
but by the book to encourage the order. This is a good book. You probably won't
write Perl in a (true) functional style, but the techniques are slick.


Site Timeline