Hacker News Reader

Comment by danieltillett | Hacker News Reader

There is some value to leaving in commented out code when you change code from something that is simple to understand to something written for efficiency. In one of my projects I have a few functions that account for most of the runtime. The original functions were easy to understand, but slow. I rewrote them using a whole series of complicated code that even I forget what it is supposed to do. It really helps me to look at the original functions to know what the hell I was tying to achieve - basically I am using simple code to document wtf code.

View on HN

One thing I've done is use those original functions as reference implementations.

Then, in the tests, have a set of sanity check calls to both the original functions and the optimized versions.

If ever they differ, the tests fail.

What do you think?

This is basically what I do.

Nice, this also ensure that the reference code stays up to date. Seeing as comments that are meant to explain could just as well be a source of confusion because of neglect.

This works until you refactor the new code, and the commented out code becomes out of sync with the production code it is supposed to mirror. Commented code isn't checked by the compiler nor by the static code analysis tools, nor by the tests, so it can become out of sync fast and silently.

Yes this is always a problem. With my own code I always update (and test) the commented out code first and only change the complex code afterwards. Since the commented code is for my benefit I think the extra work doing this is worth the cost.

The way I work is I do any changes on the 'simple' code and only once I have something that works correctly do I try to update the 'efficiency' code. I have found if I try to change the 'efficiency' code directly then after a couple of small changes (or even one) I introduce some nasty bug. The basic approach I take is simple and working first and then any optimization second.

Is the efficiency gained enough to outweigh having that "stain" in the code?

Obviously, the answer to this question will depend on a whole bunch of different factors. If given the choice, I would personally choose code readability and simplicity over efficiency.

Would you also choose readability and simplicity over correctness? Sometimes efficiency is a requirement.

>Would you also choose readability and simplicity over correctness?

Depends what you mean by "correctness" and how you determine it. In a perfect world the correct way to do something is the same thing as doing it in the most readable and simple way possible.

If you are asking if I think you should give up readability and simplicity if the appropriate standard requires it, then yes. You should probably implement and follow the standard even if the standard is shit (looking at you DOM).

> Sometimes efficiency is a requirement.

Absolutely, which is why I prefaced my opinion with:

>"Obviously, the answer to this question will depend on a whole bunch of different factors."

If you are writing performance critical code, then simplicity and readability will sometimes (probably) have to take a back seat.

Well the 'stain' is pretty small in the great scheme of things - in my projects the commented out simple code is less than 1%.

It really depends on the project, but sometimes efficiency is important and when it is having a guide to what the code is trying to achieve in a clear and simple form is really helpful.

Reply on news.ycombinator.com