Re: Perl archeology: Need help in refactoring of old Perl code that does not use strict

[AnomalousMonk]

I'd like to suggest that you also need a

Step 0: Write a test suite that the current code passes for all normal modes of operation and for all failure modes.

With this test suite, you can be reasonably certain that refactored code isn't just going to be spreading the devastation.

Given that you seem to be describing a spaghetti-coded application with communication from function to function via all kinds of secret tunnels and spooky-action-at-a-distance global variables, I'd say you have a job on your hands just with Step 0. But you've already taken a test suite into consideration... Right?

[Monk::Thomas]

This is what I would do after 'Step 0':

• identify a function using a global variable.
• verify the global variable does not change during execution of this function, e.g. some other function called by this function modifies it. (insert some code to do this for you)
• convert global variable into an argument and update all callers.

If the variable does change during the run then pick a different function first. When you got the global state disentangled a bit it's a lot easier to reason about what this code is doing. Everything that's still using a global needs to be treated with very careful attention.

[likbez]

Thank you. In this case we already have a set of test cases that can be compared and supposedly they cover all or or most of the branches.

I am reading "Perl Medic: Transforming Legacy Code" hoping to understand this problem better, and it does contain this recommendation.