2

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"?

Zach Leighton
  • 131
  • 9
  • 1
    Code debt, like with other assets, has interest - it'll get worse over time unless you actively work to reduce it; this is easier the earlier you start. Hopefully, you have a set of tests you can use to ensure you don't break your code - if not, that's the first step. Clean up everything you can, to whatever standard your team has decided on. – Clockwork-Muse Feb 09 '14 at 03:09

1 Answers1

3

TL;DR: Use automated linting and a commit hook code reformatter.

When I was doing Perl we decided to put a lint checker in our test suite, and a commit hook that automatically reformatted the code. We did this so that going forward we would not incur more technical debt from lack of code consistency and linting issues.

We didn't want to pay the time cost to bringing the entire code base up to the new standard all at once so we grandfathered them in with explicit exceptions based on the precise error the linter threw (including line number). The exception were purposely fragile so that the next time someone touched the file they would need to bring it up to the standards set by the linter.

Overtime we extended our linter and code reformatter with customizations based on our teams standards. This allowed us to use the automated tests and continuous integration to help drive out linting bugs. When the reformatter changed we would just run it en masse and commit the changes. For as many things as possible we created automated drivers to either force the change (reformat the code) or catch issue (linting). We ended driving to a fairly complete standard for ourselves. Certainly enough that we never really had a problem after to any related issue on standardization or consistency. Perhaps some on idioms to use and not use, but even some them made it into the lint extensions.

dietbuddha
  • 8,677
  • 24
  • 36