3 ms·

> Of course it helps if you can figure out what they do just from their names, but you have to read code anyway. This is, I think, the root of the (very minor)

by deong 12y ago

> Of course it helps if you can figure out what they do just from their names, but you have to read code anyway. This is, I think, the root of the (very minor) disagreement I have with your article. I really don't want to have to read the code anyway. There may be 250,000 lines of code in a moderately sized system. If I have to read a significant fraction of them to figure out what's going on, that's the biggest sin you as the original developer can commit by a couple of orders of magnitude. I want it to be obvious where to look for the code that controls whatever it is I want to change. If you make it easy for me to find those 50 lines of code, I don't care if you write them in assembler. 50 lines of anything are vastly easier to deal with than 250,000 (or god help you million) lines of the absolute best thing you can write.

valyard 12y ago
Proper naming helps but you can't 100% trust it. bool allwaysReturnsTrue() { return false; } This is of course an extreme example (8
- deong 12y ago
  Bad names are bad precisely because they force you to read a bunch of irrelevant code to have any hope of understanding what the code is doing. It's the same problem that over-abstracted code presents. In both cases, there's no forest I can look at -- just millions of individual trees. In a weird way though, bad names are actually better than many real-world problems. Once I find that code, I can change the name and the problem goes away. If you have a 100 line function full of one-letter variables, that's probably terrible. But I can spend a week poring over that function, figure out what they all do, and change the names. From that point, the function is fixed. I have no hope of fixing the problem with a big mess of fetishized design patterns. The confusion in many of these systems is baked into the core of the architecture in the form of a dozen layers of abstraction and indirection between me and figuring out the behavior of the system. Usually the only way to fix that is "rm -rf" and starting over from scratch.

by deong 12y ago

valyard 12y ago

Proper naming helps but you can't 100% trust it. bool allwaysReturnsTrue() { return false; } This is of course an extreme example (8

deong 12y ago
Bad names are bad precisely because they force you to read a bunch of irrelevant code to have any hope of understanding what the code is doing. It's the same problem that over-abstracted code presents. In both cases, there's no forest I can look at -- just millions of individual trees. In a weird way though, bad names are actually better than many real-world problems. Once I find that code, I can change the name and the problem goes away. If you have a 100 line function full of one-letter variables, that's probably terrible. But I can spend a week poring over that function, figure out what they all do, and change the names. From that point, the function is fixed. I have no hope of fixing the problem with a big mess of fetishized design patterns. The confusion in many of these systems is baked into the core of the architecture in the form of a dozen layers of abstraction and indirection between me and figuring out the behavior of the system. Usually the only way to fix that is "rm -rf" and starting over from scratch.