Philosophical coding question:

[thedutch]

You are tasked with making relatively minor changes to some established code; the code is well vetted - maybe it's survived a few release cycles.  Unfortunately, the code is poorly written.  Do you rewrite for clarity/elegance/etc, and risk a regression?

Ed: Cross disciplinary posts acceptable - If you don't code, but can decode the above, then you

Comments

[awong]

It's always a judgement call. The fundamental question is how much time will it save you over the course of the code's life. If it's a minor change, I'd say that often time, it's not worth restructuring the whole thing.

However, if you keep having to bend over backwards to make things work, then it's time to restructure. I don't have a hard rule, but usually if I have to do something stupid about 3 times in a row, I start to think very hard about refactoring/rewriting.

I'll say that recently, I've found commenting to be a relatively good compromise in many cases. Also, refactoring (in the Martin Flower, small-steps, verifying unit tests for every change sense) is a good way to make a dent w/o necessitating a full rewrite.

[thedutch]

Where's hannah's response? i'm still waiting

[zanfur]

I had a large thingy typed out, but it pretty much comes down to this: It depends.

[thedutch]

It depends is wrong - you've gotta take a stand!

[cdtwigg]

I would rewrite it in the most obscure language possible and then write some pretentious blog post about how Language X is 10x more productive than whatever it was written in before but only if you're brilliant enough to understand it. And I would make sure not to include comments because "Language X is self-documenting." How's that for taking a stand?

[thedutch]

awesome!

[aieeeeeeee]

It depends on 1) what it's used for, and 2) what else you could do with the time.

Because time is a scarce resource, you need to compare what you'd net from rewriting the code vs. what else you can get done in that time. There's always going to be more work than can get done.

It comes down to the "value" (however you define it -- whether it's hours saved in the future, or personal aggravation saved, or personal sense of achievement) of refactoring compared to the time (including fixing regressions) cost.

[mechanyx]

If this is production code the answer is, without question, "no".

Especially if you are only to make minor functional changes, if you introduce a regression that doesn't get noticed for some time and you are not on the project at that point, the changelog won't be enough for the other coders to find out where the problem is.