Menu
Reading this question I found this as (note the quotation marks) "code" to solve the problem (that's perl by the way).
100,{)..3%!'Fizz'*\5%!'Buzz'*+\or}%n*
Obviously this is an intellectual example without real (I hope to never see that in real code in my life) implications but, when you have to make the choice, when do you sacrifice code readability for performance? Do you apply just common sense, do you do it always as a last resort? What are your strategies?
Edit: I'm sorry, seeing the answers I might have expressed the question badly (English is not my native language). I don't mean performance vs readability only after you've written the code, I ask about before you write it as well. Sometimes you can foresee a performance improvement in the future by making some darker design or providing with some properties that will make your class darker. You may decide you will use multiple threads or just a single one because you expect the scalability that such threads may give you, even when that will make the code much more difficult to understand.
584
Correctness is the most important If your code is not correct at all, then it does not matter how readable or performant it is. There are some products where the whole system or part of it revolves around performance. In these cases, your product cannot be correct if it does not match the expected performance.
Code readability is one of the most important qualities of good code, like the art of writing code it's a subjective topic which varies between developers. If code is easy to read, it will be easy to understand which makes it easy to debug, maintain and extend.
Software performance only matters for a very small fraction of all source code. But what matters is the absolute value of this code, not it is relative size. Software performance is likely to be irrelevant if you have few users and little data.
JavaScript has been evolving into a more readable language. There is no doubt about that, and there is no harm either. Software development is a dynamic market where teams change constantly, meaning that the code needs to be readable for newcomers.
My process for situations where I think performance may be an issue:
Note that this does not apply to higher-level design decisions that are more difficult to change at a later stage.
183
I always start with the most readable version I can think of. If performance is a problem, I refactor. If the readable version makes it hard to generalize, I refactor.
The key is to have good tests so that refactoring is easy.
I view readability as the #1 most important issue in code, though working correctly is a close second.
33
If you love us? You can donate to us via Paypal or buy me a coffee so we can maintain and grow! Thank you!
Donate Us With
