4 ms·
Code readability is just one of the goals we aim for while designing software, performance is another, stability is another, flexibility and ability to make cha
by aszen 6y ago
Code readability is just one of the goals we aim for while designing software, performance is another, stability is another, flexibility and ability to make changes is yet another.
While reading any code I tend to think about these tradeoffs and see if that hard to read code is actually hard for a reason or simply a mess because no one took care of it.
Writing dumb easy looking duplicate code is not optimal either, I don't see an issue with stable, fast and efficient code that's harder to understand yet works brilliantly. One can easily increase readability of such code by adding comments but one can't get performance, stability and flexibility by writing comments.
Optimising for dummies just because code is easier to debug isn't a good idea, often times I have to debug easy looking code only to find that it's not that easy in execution as it was in reading. Simple code often doesn't handle all the edge cases, abstraction less code is harder to maintain and change, easy code can't evolve and grow with business needs.
It's only when code is unreadable, buggy and slow that it starts to become a real mess.
Also a shout out to Rich Hickey's distinction between easy and simple, creating simple code requires a lot more effort and thought and is not easy to just read and modify by dummies.
- kungtotte 6y agoI think a lot of the time people think they have performance issues when they in fact don't, likewise with stability and flexibility. In most cases, writing the readable and straightforward version first and only moving to the less readable but more X version (for any given value of X) after it's evident that you need to is the optimal solution. It's the programming equivalent to buying cheap tools first and only buying the expensive version once the cheap one breaks: If it breaks you used it enough to warrant the expensive and more durable one, and if it didn't break you didn't have to spend more money than necessary.
- aszen 6y agoI do see your point but let me say a bit about performance, performance matters a whole lot if your software is being used seriously all day long for getting things done in the real world. If your software is going to be someone's day job it can't afford to be slow because users would take note and complain loud and clear because it's wasting their time. Just imagine git taking 15mins for showing diffs, would you accept that for an improvement in code readability and straightforwardness. So for different industries there are different X's that matter a whole lot more than mere readability and developer convenience.
- kungtotte 6y agoI absolutely agree that performance matters a whole lot, it's one of the most important considerations in software. It's also true that many developers are not very good at spotting where and how to improve performance, and what trade-offs are appropriate, and that's what I meant. Write the straightforward version first that's easy to read so that when you need to improve performance, it's easy to use a profiler to go in and rewrite the non-performant parts in a less readable but faster way.