When is it best to change code to match standards?

Question

I have recently been put in charge of debugging two different programs which will eventually need to share an XML parsing script, at the minimum. One was written with PureMVC, and another was built from scratch. While it made sence, originally, to write the one from scratch (it saved a good deal of memory, but the memory problems have since been resolved).

Porting the non-PureMVC application will take a good deal of time and effort which does not need to be used, but it will make documentation and code-sharing easier. It will also lower the overall learning curve. With that in mind:

1. What should be taken into account when considering whether it is best to move things to one standard?

---

(On a related note)

Some of the code is a little odd. Because the interpreting App had to convert commands from one syntax to another, it made sense to have an interpreter Object. Because there needed to be communication with the external environment, it made more sense to have one object interact with the environment, and for that to deal with the interpreter exclusively.

Effectively, an anti-Singleton was created. The object would only interface with the interpreter, and that's it. If a member of another class were to try to call one of its public methods, the object would raise an Exception.

There are better ways to accomplish this, but it is definitely a bit odd. There are more standard means of accomplishing the same thing, though they often involve the creation of classes or class files which are extraordinarily large. The only solution which I could find that was standards compliant would involve as much commenting and explanation as is currently required, if not more. Considering this:

2. If some code is quirky, but effective, is it better to change it to make it less quirky, even if it is made a more unwieldy?

Answer 1

Only change it if you need to be making changes anyway. But less quirky is always a good goal. Most of the time spent on a particular piece of software is in maintenance, so if you can do something to make that easier, you'll be reducing the overall time spent on that piece of code. Nonetheless, don't change something if it's working and doesn't need any modifications.

Answer 2

In my opinion this type of refactoring is often not considered in schedules and can only be done when there is extra time.

More often than not, the criterion for shipping code is if it works, not necessarily if it's the best possible code solution.

So in answer to your question, I try and refactor when I have time to do so. Priority One still remains to produce a functional piece of code.

Answer 3

Things to take into account:

• Does it work as-is?

As Galwegian notes, this is the only criterion in many shops. However, IMO just as important is:

• How skilled are the programmers who are going to maintain it? Have they ever encountered nonstandard code? Compare the cost of their time to learn it (including the cost of delayed dot releases) to the cost of your time to refactor it.

If you're maintaining it, then instead consider:

• How much time will dealing with the nonstandard code cost you over the intended lifecycle of the codebase (e.g., the time between now and when the whole thing is rewritten)?

That's hard to guess, but consider that many codebases FAR outlive the usefulness envisioned by their original authors. (Y2K anyone?) I've gradually developed a sense of when a refactoring is worthwhile and when it's not, mostly by erring on the side of "not" too often and regretting it later.

Answer 4

If you have time, now. If you don't have time and it can be avoided, later.