This question already has an answer here:
- When to refactor 9 answers
My small team and I have created a decent sized web application (~50k lines), with a fully featured API, all in Perl. As us perl hackers know.. it is easy to get sloppy. We had to port over a lot of legacy code.. thus perl whale guts code ensued.
Long story short, we were under a fairly tight time constraint which now has been pushed back, so we have some time to go back in and standardize code.
We quickly found out how nonstandard our code was as our contractor was developing an iOS app where we have account numbers of length 10 some places, 12 in others with prepended data, etc.
As I'm going through fixing date formats and data formatting, I'm noticing a ton of really non descriptive variable and hash key naming which came from legacy code - not nice down the road maintaining it.
Basically, my question is - given the scenario above or your own experience, how far do you go when cleaning up and standardizing? Is it worth going in and replacing hash key names with longer camel cased ones, and variable names, the way data is handled in results - etc.
I know lot more pain can come from breaking working code, and it may not be worth it.. but how do you know how far to go? Get it over with now and then it pays off later, or just live with a bit of "code debt"?