

The anti-if campaign - j_baker
http://www.antiifcampaign.com/index.html

======
dspeyer
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
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
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.

------
chaosprophet
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.

~~~
amalcon
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.

~~~
mdemare
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.

~~~
j_baker
That depends on the context of course. What if that elseif branch needs to be
created in two places? Or 20 places?

------
andrewf
Not a new idea. Half of the first chapter of Fowler's _Refactoring_ is about
this.

------
aufreak2
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>)

------
mijdrol
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.

------
Prolepsis
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.

------
simonw
Evidently banishing the "new" operator (with dependency injection) wasn't
enough.

------
j_baker
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.

------
scott_s
Discussion from a few months ago: <http://news.ycombinator.com/item?id=673678>

------
cesare
The indentation in the example at the top of the page is wrong.

------
theorique
<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>

~~~
idlewords
The comma after "language" should not be there. Revoking your grammar
swastika.

~~~
teilo
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.

~~~
idlewords
No, this is not 'Nam, there are rules. If you are going to type between
grammar nazi tags, you don't get to drop in commas wherever you feel the
sentence could use one. Check any major style manual.

Keeping the swastika.

~~~
teilo
Equating grammar with a bloody war. I rest my case.

