Ask HN: Is clean code worth sacrificing performance? | Hacker News Reader

Ask HN: Is clean code worth sacrificing performance?

3 points1ilit6 comments

Basically title. How far is pushing the whole clean code thing too far?

To be more precise, I have a react app with a bunch of 'elements' that you can perform operations on. I keep them in a global state array, access them by index, and perform operations based on their type. Is it worth having an oop class hierarchy with each 'element' component containing an instance of their corresponding 'element' class that implements the logic? This will result in getting rid of the switch statement on 'element' type but will add an instance of a class to each component. Is the memory overhead worth it?

TLDR: adding a class instance to every react component or keeping the switch statements?

View on HN

I try to (generally) adhere to an approach that says do things in this order:

1. Make it work

2. Make it correct

3. Make it fast

Now that said, I'm not advocating for blinding making obviously silly decisions vis-a-vis performance, like using bubble-sort to sort an array that will clearly grow to millions of elements, etc. But I would argue for using heuristics and reasonable "rules of thumb" where performance is concerned, during the first pass, fulfill (1) and (2) and then come back to (3) as necessary. Maybe the initial implementation turns out to be fast enough. Great, ship it. If not, start doing optimization.

What does all of that have to do with clean code? Well, I'd argue that following some "clean code" like conventions (if not exactly the stuff from that book) is in the spirit of (2). Maybe we should rename that "make it correct and understandable". Anyway, I think you get the point. Start with leaning towards correct and understandable... "clean" if you want to call it that, then come back and back off some of those properties to gain performance if necessary. And of course you can relax "understandable" a bit, but you probably can't relax "correct" much if it all. After all, it doesn't matter how fast a program is if it gives the wrong results.

s/blinding/blindly

That ultimately depends not upon the actual performance or the code, but the person. I have been writing software for a very long time and in that time I have seen many people complain about performance and simultaneously measure nothing. In most cases performance is just something for people to whine about when its not them doing the work and suddenly not worth the effort when its up to them to write the performance improvements.

If you can solve for that entitlement problem you will have found your own answer to this riddle. As for my own code where I know I will always be doing the work myself increases in performance are almost always worth the effort, because the result always saves me tremendous time later and clean code is solved through some thought exercise around new organization of the code artifacts.

is this code meant to be pretty, or teach others how to do things?

or is this part of something thats never seen but serves thousands of customers per second?

It all depends on what you're using it for. The more important it is, the easier it gets to forgive "ugly".

For many things "works at all" serves, and you're better off never revisiting those things that could have been done better until they actually become a problem.

I would say default to clean clean code but allow exceptions where performance is critical, and comment it liberally. Your decision is what your exceptions are based on the rest of the code.

It depends how often it’s getting called. If you save significant memory in its current state leave it like that.

If you want to build it out with more features and give the codebase over to the next person an oop approach wouldn’t be bad.

In general I would prefer clean code.

Reply on news.ycombinator.com