3 ms·

I hate code like that. A lot. It means that you can never trace control-flow. You see a function call you don't know where it goes. And all the underlying l

by dspeyer 17y ago

I hate code like that. A lot. It means that you can never trace control-flow. You see a function call you don't know where it goes. And all the underlying logic is hidden. There's no telling how many files you'll have to dig through to find the callee. It also means there's no locality. When you have an if statement, the condition, action and alternative are all right next to eachother. With virtual functions, there in at least three different files. By the time you find one, you've forgotten the others. Finally, it bulks code horribly with boilerplate. You can see that just with the examples on the site. This means less working code fits in an editor window, which means more bugs. Anyone who believes this should try maintaining some low-if code of reasonable age. That will cure them quickly.

j_baker 17y ago
As with everything in programming, it's about tradeoffs. Should you complicate your class hierarchy just to get rid of a lousy if statement? Probably not. Should you make that gigantic switch statement be polymorphic? Definitely. Should you replace repeated if statements with polymorphism? Probably. Locality of reference is a good thing, but there is a point where you need to break things down in to smaller, more understandable chunks. And if statements are no different.
- dspeyer 17y ago
  I've always found a good principle to be that functions should do something and classes should be something and it should be possible to explain what that something is in a short sentence. If an if or switch statement can become a map of function pointers or a polymorphic dispatch without violating this principle, go for it. If not, use "if". Even if you have to use a lot of "if", it'll make your code make sense. A related principle is that a function's argument list should never be longer than its body.
mdemare 17y ago
Locality - a word to remember. As soon as you extract a method, or turn a switch statement into classes with polymorphism, or introduce a MVC pattern, you hurt locality, and that kills readability, like an essay with dozens of footnotes. All those things have their advantages, but people are too quick to sacrifice locality.

by dspeyer 17y ago

j_baker 17y ago

As with everything in programming, it's about tradeoffs. Should you complicate your class hierarchy just to get rid of a lousy if statement? Probably not. Should you make that gigantic switch statement be polymorphic? Definitely. Should you replace repeated if statements with polymorphism? Probably. Locality of reference is a good thing, but there is a point where you need to break things down in to smaller, more understandable chunks. And if statements are no different.

dspeyer 17y ago
I've always found a good principle to be that functions should do something and classes should be something and it should be possible to explain what that something is in a short sentence. If an if or switch statement can become a map of function pointers or a polymorphic dispatch without violating this principle, go for it. If not, use "if". Even if you have to use a lot of "if", it'll make your code make sense. A related principle is that a function's argument list should never be longer than its body.

mdemare 17y ago

Locality - a word to remember. As soon as you extract a method, or turn a switch statement into classes with polymorphism, or introduce a MVC pattern, you hurt locality, and that kills readability, like an essay with dozens of footnotes. All those things have their advantages, but people are too quick to sacrifice locality.