5 ms·
I mostly disagree with the article. > Is the code readable? Readable code may not be good code. More readable code almost always means less efficient code. Re
by d--b 9y ago
I mostly disagree with the article.
> Is the code readable?
Readable code may not be good code. More readable code almost always means less efficient code. Readability is a trade off.
> Is it easy to extend?
Changing requirements are a thing for sure. But in almost every cases I came across, planning for shifting requirements always misses the point. It is much better to stick to your current requirements and keep your code simple, than introduce things that complicate your code for requirements that may or may not happen. Extending simple code is simpler than undoing code and replace.
> Is your code efficient?
It's very hard to self determine whether one own's code is efficient. Almost every one will think their code is efficient.
> can you write it quickly?
Again people tend to think that they are fast at writing code whatever their actual speed.
-- the reality is that it's really hard to qualify good or bad code. Self assession is particularly useless.
- olavk 9y ago> More readable code almost always means less efficient code. Incorrect. Most practices like meaningful variable names, logically separated functions and classes, comments where appropriate, etc have absolutely no impact on performance. Principles like DRY and KISS and YAGNI typically also lead to better performance. Only in rare isolated cases might there be a conflict, eg. where a more cryptic algorithm have better performance than the straightforward.
- BurningFrog 9y agoPlanning for extending the code is the wrong way to think about it. To many that means overgeneralized code, which is a terrible. The right way is to write modular code, where each class/function has simple and clear responsibilities. In that kind of code, changes are usually isolated and clear.
- jplasmeier 9y ago"More readable code almost always means less efficient code." Can you give examples? I'm not sold that the "low hanging fruit" of readability improvement (empty lines to break up "paragraphs", breaking up unintelligible one-liners into several lines, etc.) degrades performance. My intuition is that the compiler/interpreter ends up producing almost identical runtime code and therefore similar performance. Unless you mean more along the lines of expressivity (i.e Python and Ruby can get a lot done with fewer statements compared to C), but to me this effect is in a different category than readability.
- wolfgang42 9y agoTake the following code, which I had occasion to write this morning: foreach (var item in items) { if (items.Where(item2 => item.Upc == item2.Upc).Count() != 1) { item.Duplicate = true; } } This is the most readable and straightforward code I could come up with for the task; it's also not particularly efficient, since it does at least twice as many comparisons as necessary (more if there are actually duplicate items). To make it more efficient would require extra loops and manually indexing them to skip over comparisons that had already made; in this context I decided against this because the performance impact was minimal since there are other far less efficient portions of the code which would best be addressed first if the program turns out to be too slow.
- dozzie 9y agoEver heard of these things called "hashes" a.k.a. "dictionaries"? They are magical boxes for elements that are indexed by name. You build such a magical box of seen elements while going through the checking loop and you get the time complexity of O(n) or O(n log(n)) instead of your current O(n^2), so it won't explode when you get more elements passing through the code. Note that this was conceived in just a few minutes of reading your code, deciphering syntax only remotely familiar, and figuring out what was it supposed to do, all with cold start (I haven't written much today yet). Something went wrong with your thought process.
- wolfgang42 9y agoFirst, a small correction: the if statement in my original code can actually be written as the following, which is what I had in the actual code: if (items.Count(item2 => item.Upc == item2.Upc) != 1) With that correction out of the way, here's the code if I used a HashSet (you suggest 'a. k. a. "dictionaries"' but that is slower and I don't need the other half of the mapping which they would provide): var set = new HashSet<string>(); foreach (var item in items) { if (set.Contains(item.Upc)) { item.Duplicate = true; } else { set.Add(item.Upc); } } To my eye, this is less readable; in addition to having twice as many lines and an extra variable, it also takes extra work to figure out what it does; whereas my version does exactly what it says: if the UPC appears more than once, it marks the item as a duplicate. For a final comparison, here's an implementation of the extra loops and manual indexing I suggested: for (var i = 0; i < items.Count; i++) { for (var j = i + 1; j < items.Count; j++) { if (items[i].Upc != items[j].Upc) continue; items[i].Duplicate = true; items[j].Duplicate = true; break; } } This isn't significantly longer than the HashSet-based version, but it is even faster to run (I just benchmarked it) and also doesn't use an extra object which takes memory and needs to be managed and garbage-collected later. In conclusion, while I appreciate your suggestion for a possible alternative implementation, I do not appreciate your impugning of my abilities with the suggestion that "something went wrong with your thought process", and implying that I may not be aware of basic data structures.
- mrisoli 9y agoI share the same opinion, TBH, there's much more to being a good programmer than writing good code.