3 ms·

Ten characters of unreadable code written by an expert will have fewer bugs than 100,000 lines of "readable, clear" C++ code written by a novice. E

by zaphar 8y ago

Ten characters of unreadable code written by an expert will have fewer bugs than 100,000 lines of "readable, clear" C++ code written by a novice. Everytime this topic comes up someone brings up this point. The counter to it is always the same. In the lifetime of those ten characters someone who is not the original author will have to modify it. Because it is not clear what exactly the code is doing they will probably introduce a subtle bug. Iterate on that a few times and eventually you will have code that literally no one can safely touch and the only way to fix it will be to rewrite it. If the person doing the rewrite is smart and looks at why the rewrite was necessary they will change those "ten characters" to however many it takes to make it understandable for the future maintainer. It should be exactly as short as necessary to be clearly correct and no shorter. Then you can work at making it faster with appropriate comments about why this particular speed hack is necessary and what you need to know before you modify it.

jodrellblank 8y ago
You want a large amount of code, because you're afraid of maybe having to rewrite a small amount of code? How does that make sense, and why won't the large amount go through the same iterative adjustment and subtle bugs until it needs rewriting? Because it is not clear what exactly the code is doing A ten character English which name vaguely describes what a function hidden in another file might have been doing (assuming you understand the word in the same way the author did when they chose it) at the time it was written - but it might not be doing the same thing now since it was edited so many times, is not exact. By contrast, ten dense characters right there under your nose is exact - as much as a programming language can be. There's nothing hidden, no surprises, no unseen side effects, no uncertainty about whether it handles edge cases. Code is as exact as it gets - it does what the language does. Abstractions are less exact - they do some version of what the previous chain of developers intended the words to imply that they do, in the best case. In worse cases they also do unrelated and surprising things. And you dodged every question about when slow but correct code won out over faster, more buggy code.
- zaphar 8y ago
  It's not about the length of the code. It's about how understandable it is. I think we are talking past each other so I'll bow out now. We can agree to disagree.

by zaphar 8y ago

jodrellblank 8y ago

You want a large amount of code, because you're afraid of maybe having to rewrite a small amount of code? How does that make sense, and why won't the large amount go through the same iterative adjustment and subtle bugs until it needs rewriting? Because it is not clear what exactly the code is doing A ten character English which name vaguely describes what a function hidden in another file might have been doing (assuming you understand the word in the same way the author did when they chose it) at the time it was written - but it might not be doing the same thing now since it was edited so many times, is not exact. By contrast, ten dense characters right there under your nose is exact - as much as a programming language can be. There's nothing hidden, no surprises, no unseen side effects, no uncertainty about whether it handles edge cases. Code is as exact as it gets - it does what the language does. Abstractions are less exact - they do some version of what the previous chain of developers intended the words to imply that they do, in the best case. In worse cases they also do unrelated and surprising things. And you dodged every question about when slow but correct code won out over faster, more buggy code.

zaphar 8y ago
It's not about the length of the code. It's about how understandable it is. I think we are talking past each other so I'll bow out now. We can agree to disagree.