Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Anti-if: The Missing Patterns

code.joejag.com

Post reply on HN
Print view View original

11–20 of 74 posts

Re: Anti-if: The Missing Patterns

#11

Post by peterevans »

a3n wrote: post #9

> Patten 3: NullObject/Optional over null passing The solution here disperses the responsibility of keeping sumOf safe to its callers, all over the place, instead of a single location in sumOf.

Agreed. The sumOf function is now made more brittle by that fact, and would be unworkably so in a publicly-available API. This is easily fixed by a try-catch block if one finds that they are indeed allergic to if statements, although that too is a form of flow control. If you are programming in Go, you're going to have to bite the bullet and use an if.

(I suspect the author would prefer jumping in a lake over programming in Go.)

I think it is also worth mentioning that passing a new ArrayList over a null value is somewhat wasteful of memory. Though the reference to ArrayList will cease to exist, its allocated memory will hang out until the next GC phase. In the words of Bartleby, I would prefer not to.

I get the principle that is being advocated, but the solution code doesn't pass practical muster for me.

Re: Anti-if: The Missing Patterns

#12

Post by dfox »

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.

Re: Anti-if: The Missing Patterns

#14

Post by wereHamster »

tgb wrote: post #7

I'm afraid the article has left me unconvinced. I'm open to having my mind changed on the matter, though. 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 whatso…

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

If you always use `Option` (or whatever equivalent your language/base library provides) and banish `null` from your source code you've effectively avoided all null pointer exceptions and can therefore remove all null checks.

Re: Anti-if: The Missing Patterns

#15

Post by kazinator »

wtetzner wrote: post #2

> Context: You have a method that takes a boolean which alters its behaviour > 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. 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 ou…

Common Lisp to the rescue!

   (defmethod make-sound ((b bear) (loud-p t)))
    ;; bear makes loud sound
     ...)

   (defmethod make-sound ((b bear) (loud-p null))
    ;; bear makes quiet sound
     ...)
If we call (make-sound bear-instance nil), the second method is invoked because loud-p is specialized to the null class, whose only instance is nil. (There is a type nil also, whose domain is the empty set: it has no instance.)

If we call (make-sound bear-instance ), then the first specialization takes over. It's specialize to T, the grand superclass, so it is a fallback that takes anything. Any value other than nil serves as a Boolean true in Lisp.

It's a magic of Lisp that T stands for "any type" as well as "true". :)

I don't know whether treating Booleans as method parameters like this is good design, but I don't see any immediate down sides.

Re: Anti-if: The Missing Patterns

#16

Post by michaelmior »

One thing I've always done with if statements is when I have an if with a negated condition and no else case

    if (!condition) {
      // do stuff
    }
When I want to add an else case, I swap the order so the condition is no longer negated.

    if (condition) {
      // do other stuff
    } else {
      // do stuff
    }
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".)

Re: Anti-if: The Missing Patterns

#20

Post by userbinator »

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

http://www.codeproject.com/Articles/42732/Table-driven-Appro...

Post reply on HN