I'm disappointed that of all the patterns presented, most of them actually increase the complexity to some extent, and none of them are the use of a lookup table/array. IMHO that is the "real anti-if pattern" here, and it can <i>immensely</i> simplify code. I've taken long, convoluted nested if/else chains with plenty of duplication and turned them into a single array lookup. A bonus is that performance and size often benefit as well, since the code is far less branchy.<p><a href="http://www.codeproject.com/Articles/42732/Table-driven-Approach" rel="nofollow">http://www.codeproject.com/Articles/42732/Table-driven-Appro...</a>
> Context: You have a method that takes a boolean which alters its behaviour<p>> Problem: Any time you see this you actually have two methods bundled into one. That boolean represents an opportunity to name a concept in your code.<p>This is only true if you're using literal booleans at you call sites. If the booleans are coming from somewhere else, like user input, you just moved your single if statement in the method out to every call site.<p>> Context: You are calling some other code, but you aren’t sure if the happy path will suceceed.<p>> Problem: These sort of if statements multiply each time you deal with the same object or data structure. They have a hidden coupling where ‘null’ means someting. Other objects may return other magic values that mean no result.<p>Passing a default value works, but in Java 8, returning an Optional is cleaner. And if you wanted a default value, you can still do<p><pre><code> repository.getRecord(123).orElse("Not found");
</code></pre>
Edit: Also, the coping strategy link [1] he gave to remove exceptions sounds a lot like restarts in Commons Lisp's condition system.<p>[1] <a href="https://silkandspinach.net/2014/11/06/on-paperboys-newsagents-and-exceptions/" rel="nofollow">https://silkandspinach.net/2014/11/06/on-paperboys-newsagent...</a>
I'm afraid the article has left me unconvinced. I'm open to having my mind changed on the matter, though.<p>The point of passing boolean params instead of named functions is that most of the time there is shared code between the two paths and not literally all the code is enclosed in either the if or the else block. If the author was intending just to restrict to that one specific case where there was no overlap whatsoever, then I guess I would agree but I'm not sure how often that happens.<p>Polymorphism has some advantages but it's certainly got it's own troubles in terms of understand-ability. The author links to an article which even states "I think that we hate conditionals more than we should. Introducing polymorphism too soon will complicate your code, making it hard to understand and test." It then goes on to give an example where it says polymorphism is actually the right choice, to avoid two switches. I'd say that at least this trivial example would be best handled by some data-driven approach. Look up salaries in a database instead.<p>The inline statement one can certainly be better in some cases, but the example given is quite poor. What does "foo && bar || baz" mean? Well, now I have to remember the order of operations ... 'or' after 'and' I guess. Surely this is easier to misread than the if statement example, which in my mind closely matches how I think. At least it should be "(foo && bar) || baz". But even then, that only works when the actual return type is boolean and there are no state changes made.<p>I don't really see how using an Optional type would remove the if(null) checks. It just makes the meaning explicit, which is good but not remedying the original problem.<p>5 seems nice.
I had a professor in university who was frequently saying he developed a thousand application and he didn't use any if.<p>I know it's extreme but is there any way to reduce (lets say 5 to 1) conditions?<p>I think he was developing Fortran apps.<p>Anecdote: This very same professor asked us to do a matrix operation (I don't remember what) without using if once. He said it would be faster than using ifs. Many of us couldn't. Then he revealed his solution, he was getting first indice of first row and doing some operation and getting the last indice of last row, then second indice of first row and so on.
One of my friend told that if he wrote the algorithm plain using ifs, it would be faster. Professor told it's impossible.<p>In the end of the day the version which was written using ifs was a lot faster than the version without ifs. Because of the changing indices cause a lot of cache misses but getting matrix elements sequentially used cache correctly.
All of the proposed solutions are deficient:<p>> Pattern 1: Boolean Params<p>This solution suffers from what we typeful programmers call “Boolean blindness”: <a href="https://existentialtype.wordpress.com/2011/03/15/boolean-blindness/" rel="nofollow">https://existentialtype.wordpress.com/2011/03/15/boolean-bli...</a> . When you compute a bit, what you are actually interested in is the <i>meaning</i> of the bit, which isn't included in the bit itself. For example, if the bit is set, then “x” is less or equal than “y”; if it's unset, then “x” is greater than “y”.<p>> Pattern 2: Switch to Polymorphism<p>Dynamic dispatch (what the author wrongly calls “polymorphism”) can be used for <i>open-ended</i> case analysis. But it suffers from two drawbacks: (0) Unless you have multimethods, case-analyzing two or more values at the same time is a bitch! (1) Even if you do have multimethods, the open-ended nature of this whole business makes static exhaustiveness checking (making sure that no case is missing) impossible.<p>> Patte[r]n 3: NullObject/Optional over null passing<p>Null objects are still falling back to pattern 2, and optionals are severely underpowered in languages without pattern matching and compile-time exhaustiveness checks. For instance, one of my favorite patterns is implementing operations (say, “merge”) on non-empty collections, then extending them to possibly empty ones:<p><pre><code> (* pe = possibly empty *)
datatype 'a pe = Empty | Cons of 'a
(* extend a merge operation on non-empty collections
* to possibly empty ones *)
fun pointed _ (xs, Empty) = xs
| pointed _ (Empty, ys) = ys
| pointed op++ (Cons xs, Cons ys) = Cons (xs ++ ys)
fun merge (xs, ys) = ... (* possibly complicated *)
and mergePE args = pointed merge args
</code></pre>
How do Java-style optionals help?<p>> Patte[r]n 4: Inline statements into expressions<p>This only makes the problems associated to Boolean blindness even worse.<p>> Pattern 5: Give a coping strategy<p>What if there is no sensible default value? Just... no.<p>---<p>What you really need is algebraic data types, pattern matching and exhaustiveness checks.
Uhm. No, no, no, no and no.<p>> [Pattern 1] Solution: Split the method into two new methods. Voilà, the if is gone.<p>And so is parametrization.<p>> [Pattern 2]: Solution: Use Polymorphism. Anyone introducing a new type cannot forget to add the associated behaviour.<p>OTOH you make extensions more complex. I usually write in lisp and DO NOT use polymorphism for this but etypecase in the base implementation of a method (switch/case where the default case automatically throws an error). This allows people who extend my code to implemented a method specific to a type that my base implementation handles and thereby overriding my implementation with minimal effort.<p>> [Pattern 3]: Solution: Use a NullObject or Optional type instead of ever passing a null. An empty collection is a great alternative.<p>This is, IMHO, not relevant at all - the decision how null values are handled simply has to be documented so programmers can make an informed choice. The only exception I accept is an empty collection which I'll always prefer over null, assuming that all other code handles empty collections gracefully.<p>> [Pattern 4]: Solution: Simplify the if statements into a single expression.<p>Works for the contrived example (and we all know that the code is really bad). For more complex code I rather follow the logic line by line instead of mentally disassembling a 10 line boolean expression.<p>> [Pattern 5]: Solution: Give the code being called a coping strategy.<p>No, just no. One does not aim at removing exceptions. Those are to be handled by a higher layer who actually knows how to handle it. If one uses default values one still has to check on that layer with the added burden of using a default value that is guaranteed to never be returned as a real value so we can make the distinction between record found/record not found.
Misko Hevery did a Google Tech Talk about this some years ago, he also use a very similar example with switching on the birds.<p><a href="https://www.youtube.com/watch?v=4F72VULWFvc" rel="nofollow">https://www.youtube.com/watch?v=4F72VULWFvc</a>
One thing I've always done with if statements is when I have an if with a negated condition and no else case<p><pre><code> if (!condition) {
// do stuff
}
</code></pre>
When I want to add an else case, I swap the order so the condition is no longer negated.<p><pre><code> if (condition) {
// do other stuff
} else {
// do stuff
}
</code></pre>
To me it's easier to read a non-negated condition and the else case then feels more natural. (It avoids having to internally think about else case as "condition not not satisfied".)
Using 'if' indicates programmer's doubts about what a program should do. These are usually rooted in low self esteem and troubled relationships with parents.
If you want extreme case of removing all ifs, see how ifTrue: and friends are implemented in Smalltalk (ie. true and false are instances of different classes), although essentially all compiler implementations turn that into normal conditional branches in generated bytecode.
All these complicated examples and no mention of functional pattern matching or pattern matching at all.<p>IMHO These are by far the two most important ways to get rid of complex code embedded with ifs.<p>One very good example of this is erlangs factorial method.<p><pre><code> factorial(0) -> 1;
factorial(N) -> N * factorial(N-1).
</code></pre>
There are many other nice examples at the erlang documentation:<p><a href="https://www.erlang.org/course/sequential-programming#funcsyntax" rel="nofollow">https://www.erlang.org/course/sequential-programming#funcsyn...</a>
Generally speaking, for every refactoring you could do, the opposite move is sometimes useful too. For example, inlining a function and extracting a helper function could both be a way to simplify code, depending on what you're trying to do.<p>Similarly here, I think it's good to know how to get rid of an if statement, but keep in mind that sometimes you might want to introduce an if statement. Sometimes you want polymorphism and sometimes it's better to do the same thing as pattern matching.
> Patten 3: NullObject/Optional over null passing<p>The solution here disperses the responsibility of keeping sumOf safe to its callers, all over the place, instead of a single location in sumOf.
This reminds me of something I read on HN a while back and forgot to bookmark. (Naturally I've been unable to find it since.)<p>I think the article was written by a company who made a static code analysis tool. They described how there wasn't a large difference in quality between FOSS and proprietary code, except for one detail: FOSS code used "else" statements much less.<p>Anyone have any idea what I'm thinking of or if I'm even remembering it correctly?
And if there is no record in the repository, what should I do with the default value? Check if the returned value is different from the default? I actually don't see any real benefit in cleanliness. The only thing that could actually happen is using the default in some way that could eventually bring the data in some strange state. An NPE would at least shout "YOU MESSED SOMETHING UP" in my face.
Pattern 5 is all about removing semantic value from null references, but has nothing to do with if statements... In fact, the if-else remains (albeit hidden because of an early return inside an if, which is even worse in my opinion).
I'm surprised there was no mention of the Specification pattern.<p><a href="https://en.wikipedia.org/wiki/Specification_pattern" rel="nofollow">https://en.wikipedia.org/wiki/Specification_pattern</a>
I'm quite supportive to the anti-if pattern but the presented example sounds me more like "code smells" and doesn't really makes me happy
to me anti-if is a great winner when you can safely compute all the execution path in advance (in a way where you have not to nest ifs, of course!) but in situations where your code have to react to something that happens "on the moment"... well, probably "if" are more convenient (not always of course)
anyway thanks to have raised the point, this topic is always interesting to me