If you have to pay the price of performance to make code more readable would you prefer that or you would always prefer performance over it?
closed as primarily opinion-based by user40980, Robert Harvey♦, user16764, GlenH7♦, JeffO Jul 10 '13 at 16:53
Many good questions generate some degree of opinion based on expert experience, but answers to this question will tend to be almost entirely based on opinions, rather than facts, references, or specific expertise. If this question can be reworded to fit the rules in the help center, please edit the question.
In layman's words:
- Making the code ugly does not make it fast.
- Making the code clean does not make it slow (or fast).
- Making the code ugly does make the maintainer's work slower.
- Clean code usually means the code was made by someone who cares.
- One who cares to make his code clean, usually cares to make it efficient.
- Hardware becomes cheaper with time.
- Programmers don't get cheaper over time.
- CPU time is cheaper than programmer's time.
- Some performance problems can be solved by throwing money at them.
- Very few code maintainability problems can be solved by throwing money at them.
You should always choose clean code first as it reduces the cost of maintenance and it likely to be less complex. You shouldn't address a performance problem that you haven't identified; that's probably a premature optimisation.
The general idea is to make the code as readable as possible first, and then only look at optimizing where there's a proven performance problem. In most cases a response time of, e.g. 5 ms instead of 1 ms isn't going to make a difference. 50 seconds instead of 10 seconds is a different matter.
Prefer meeting your customer's requirements.
If the customer has imposed a performance requirement, and that requirement dictates that you change the code to make it less readable but more performant, then you change the code to make it less readable but more performant.
But ugly fast code is a false dichotomy. Sometimes you can make code perform better without making it significantly more ugly.
If the code already performs adequately, then prefer readability over more performance.
Measure first, then optimize the slow bits only if you need to do so to meet the requirements.