The anti-if campaign(antiifcampaign.com)
antiifcampaign.com
The anti-if campaign
http://www.antiifcampaign.com/index.html
11 comments
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.
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.
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.
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.
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.
A related principle is that a function's argument list should never be longer than its body.
I have never seen any reason to consider if statements to be evil enough that I should absolutely avoid them in my code. AFAIK, this is one of those pointless movements.
If anybody can explain why ifs are supposed to be so horrible, then perhaps I might change my mind.
If anybody can explain why ifs are supposed to be so horrible, then perhaps I might change my mind.
It looks like the complaint is against using IF when type polymorphism would be more appropriate (usually of the form "if(x instanceof a)"). It is almost never a good idea to use IF in those cases, but frankly, this website does not do a good job of explaining the problem.
To replace `if(x instanceof a)`, you don't need type polymorphism (way too heavy). You need algebraic datatypes. With pattern matching (a glorified `switch`), you have the best of both worlds: the compiler make sure you cover all cases (and warn you if you don't), and the code is still local (you don't have to fetch several files to assess its behaviour). If you want to add one case, you still have to modify several snippets, but again, the compiler will warn you if you forget one.
Of course, if their language don't have algebraic datatypes, I strongly suggest they learn one that have it.
Of course, if their language don't have algebraic datatypes, I strongly suggest they learn one that have it.
Isn't that a minimal use-case??? The presentation of the site seems to suggest that any and all IF statements are to be avoided (though i have to admitted I did'nt get past the landing page).
And even in those cases, it isn't cut-and-dried. They claim "The advantage is that tomorrow, we can fulfill the request for a new type of bond by simply creating a new class, with the single required logic to calculate the value of that new bond."
Simply? I'd say that creating a new class is a hell of a lot more work than creating a new elseif branch.
Simply? I'd say that creating a new class is a hell of a lot more work than creating a new elseif branch.
That depends on the context of course. What if that elseif branch needs to be created in two places? Or 20 places?
Although it's not what the site is talking about, I think it's often a lot more readable when many "if"s are replaced with "switch" statements or their big brother, ML-style pattern matching. Those make it more clear when conditions are mutually exclusive and help eliminate the error-prone simplification of boolean conditions in your head.
Not a new idea. Half of the first chapter of Fowler's Refactoring is about this.
I think the observation that conditionals are difficult to work with is valid, however the suggestion that "proper use of object oriented principles" is the solution to that problem is totally mistaken. To understand why I say that, watch Jonathan Edwards presentation "No Ifs, Ands or Buts" about Subtext (http://subtextual.org/subtext2.html)
Yeah, no big deal here, it's not a matter of ifs or not ifs, it's a matter of using the object oriented paradigm properly, and not being stupid. No point in creating a website about it.
Anyway, pattern matching + static typing is much more convenient.
Anyway, pattern matching + static typing is much more convenient.
I don't think websites like this will make any difference. People who misuse if statements are either beginning programmers or people who don't want to learn new stuff anyway.
Another problem is that if you only read the front page it only says if statements are bad. If you are a beginning programmer it probably sounds like nonsense if you don't get a reason.
Another problem is that if you only read the front page it only says if statements are bad. If you are a beginning programmer it probably sounds like nonsense if you don't get a reason.
Evidently banishing the "new" operator (with dependency injection) wasn't enough.
Just an FYI, I didn't post this because I agree with it 100%. I just find it fascinating that there's an entire campaign against removing if statements.
[deleted]
Discussion from a few months ago: http://news.ycombinator.com/item?id=673678
The indentation in the example at the top of the page is wrong.
<grammarnazi>
It would be great if a site promoting better use of (computer) language, exhibited better use of (human) language.
Not 'less' ifs, people, 'fewer' ifs! </grammarnazi>
Not 'less' ifs, people, 'fewer' ifs! </grammarnazi>
http://itre.cis.upenn.edu/~myl/languagelog/archives/003775.h... suggests your fervency is misplaced.
The comma after "language" should not be there. Revoking your grammar swastika.
Wrong. The rule of the optional comma is: Add them where it aids the readability of your sentence by breaking up your clauses.
Punctuation was made for the reader, not the reader for punctuation.
Punctuation was made for the reader, not the reader for punctuation.
Agreed, I read the comma before people as adding emphasis, almost like saying PEOPLE.
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.