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

31–40 of 74 posts

Re: Anti-if: The Missing Patterns

#31

Post by adrianratnapala »

userbinator wrote: post #20

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 benef…

"Polymorphism" kind of counts, it replaces the switch-case with a vtable lookup.

Re: Anti-if: The Missing Patterns

#32

Post by mercer »

eyan wrote: post #17
akkartik wrote: post #8

This recent article seems relevant: http://www.sandimetz.com/blog/2016/6/9/make-everything-the-s...

This is actually a better read than the OP. Thank you.

I only read bits and pieces of "Practical Object-Oriented Design in Ruby" by Sandi Metz, and the occasional article, but all of it has been surprisingly beneficial to my day to day coding.

Re: Anti-if: The Missing Patterns

#33

Post by mercer »

michaelmior wrote: post #16

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 a…

Interesting. I often (but not always) prefer the if (!condition) {} at the top because I see it as 'bailing out' of the function if conditions are not met.

Re: Anti-if: The Missing Patterns

#34

Post by RodgerTheGreat »

peterevans wrote: post #11
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 program…

In this very specific instance, you could easily and idiomatically reuse a single instance of an immutable empty list:

https://docs.oracle.com/javase/7/docs/api/java/util/Collecti...

No dynamic heap allocation necessary.

Re: Anti-if: The Missing Patterns

#35

Post by bbcbasic »

cle wrote: post #23
userbinator wrote: post #20

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 benef…

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.

C# will optimise something like >7 items in a switch statement to a lookup. Funny how this doesn't play nice with code contracts!

Re: Anti-if: The Missing Patterns

#37

Post by mikkom »

All these complicated examples and no mention of functional pattern matching or pattern matching at all.

IMHO These are by far the two most important ways to get rid of complex code embedded with ifs.

One very good example of this is erlangs factorial method.

   factorial(0) -> 1;
   factorial(N) -> N * factorial(N-1).
There are many other nice examples at the erlang documentation:

https://www.erlang.org/course/sequential-programming#funcsyn...

Re: Anti-if: The Missing Patterns

#38

Post by hvidgaard »

yildirim wrote: post #29

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

The performance cost of ifs are not that bad. Especially if it means you can read sequentially from the memory.

It however, do represent branching, and in a hotspot it can be more efficient to simply calculate both the if and the else and just choose the right value, rather than having a branch misprediction.

In any case, always profile, and identify issues before doing any optimization.

Re: Anti-if: The Missing Patterns

#39

Post by salex89 »

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.
Post reply on HN