Anti-if: The Missing Patterns
I&#x27;m afraid the article has left me unconvinced. I&#x27;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&#x27;m not sure how often that happens.<p>Polymorphism has some advantages but it&#x27;s certainly got it&#x27;s own troubles in terms of understand-ability. The author links to an article which even states &quot;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.&quot; It then goes on to give an example where it says polymorphism is actually the right choice, to avoid two switches. I&#x27;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 &quot;foo &amp;&amp; bar || baz&quot; mean? Well, now I have to remember the order of operations ... &#x27;or&#x27; after &#x27;and&#x27; 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 &quot;(foo &amp;&amp; bar) || baz&quot;. But even then, that only works when the actual return type is boolean and there are no state changes made.<p>I don&#x27;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.