Anti-if: The Missing Patterns

Uhm. No, no, no, no and no.

> [Pattern 1] Solution: Split the method into two new methods. Voilà, the if is gone.

And so is parametrization.

> [Pattern 2]: Solution: Use Polymorphism. Anyone introducing a new type cannot forget to add the associated behaviour.

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.

> [Pattern 3]: Solution: Use a NullObject or Optional type instead of ever passing a null. An empty collection is a great alternative.

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.

> [Pattern 4]: Solution: Simplify the if statements into a single expression.

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.

> [Pattern 5]: Solution: Give the code being called a coping strategy.

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.

I do this a lot too. Often long chains of if statements are really performing a manual mapping from one set of values to another. Just keep a map and perform a lookup! Easier to read, easier to change, and easier to extend since the mapping is a data structure instead of code.

All of the proposed solutions are deficient:

> Pattern 1: Boolean Params

This solution suffers from what we typeful programmers call “Boolean blindness”: https://existentialtype.wordpress.com/2011/03/15/boolean-bli... . When you compute a bit, what you are actually interested in is the meaning 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”.

> Pattern 2: Switch to Polymorphism

Dynamic dispatch (what the author wrongly calls “polymorphism”) can be used for open-ended 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.

> Patte[r]n 3: NullObject/Optional over null passing

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:

    (* 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

How do Java-style optionals help?

> Patte[r]n 4: Inline statements into expressions

This only makes the problems associated to Boolean blindness even worse.

> Pattern 5: Give a coping strategy

What if there is no sensible default value? Just... no.

---

What you really need is algebraic data types, pattern matching and exhaustiveness checks.

> 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 you have this

    method(bool arg)
    {
      // block A
      if (arg)
      {
        // block B1
      }
      else
      {
        // block B2
      }
      // block C
    }

you can replace it with

    method1()
    {
      A();
      B1();
      C();
    }
    
    method2()
    {
      A();
      B2();
      C();
    }

where A(), B1(), B2() and C() are new methods that contain the previous blocks. This makes the code clearer, IMO.

I had a professor in university who was frequently saying he developed a thousand application and he didn't use any if.

I know it's extreme but is there any way to reduce (lets say 5 to 1) conditions?

I think he was developing Fortran apps.

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.

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.