You have received a horrible code at work, what will you do?

This was an actual interview (which I failed) question I was asked.

---

The answer I said (Mostly focused on styling/structure)

Bad code might have its own purpose.

Even if the code looks messy, there might be the reason that it has been written that way. Or, at least, people are already used to it. Changing an existing schema will cause confusion and harm to productivity.

It could be waste of time to fix it.

Even though There is no reason to keep the code, fixing it might be a waste of your time, especially if when the code is not used constantly. You need to determine first if it is necessary to fix it.

The answer I have found online (focused on debugging)

Clarifying comments

figure out what the code does and try to clear it out by stating with comments for yourself and the next person rather than touch actual code to risk breaking

No risk fix

add a special case. It would be safer and faster, but the real issue wouldn't be fixed.

Delete and Rewrite

Just threw away everything and do again from scratch.

Whoever wrote this is an idiot.

It would be clean and simple.

---

What do you think would be the best option? Do you have another good idea? Please share your opinion.

Comments

[Brad]

Assuming a best-case scenario where I have time to commit to refactoring, I actually understand what the code is doing, and there is at least some supporting code like tests, comments, docs, etc.

• I'd write some test-cases if possible, to verify the current existing behavior of the code. If it isn't possible or easy to test, I'd try to refactor it so I could test it. If its still hard to test, it might be too far gone.
• I'd do some no-risk refactoring, clean up comments, format, etc.
• I'd be damn well sure I understand what the code is doing, with or without tests.

---

In the worst case, where I can't write tests, its extremely complicated and extremely critical, I'd try to do as little as possible to it to prevent any breakage down the line. I'd also keep the code in mind as a candidate as a refactor/re-write.

I believe if you can write tests for code, you can refactor it much easier, without worry. If you can't write tests for dirty/ugly code, then changing it is risky, and since not all code can be tested easily it might not be worth the risk and work, especially if the code works.

[Juneau Lim]

I feel sorry for putting you in an undesirable position. My apology for that, and thanks for your insight.

[Juneau Lim]

What a helpful mentor you are. I hope to meet someone like you when I start working. Thanks for your answer.

[Juneau Lim]

So there are even more cases then I originally thought. Never make an assumption is also a good lesson. Thanks you for that.