Anti-if: The Missing Patterns • Hacker News Board

Re: Anti-if: The Missing Patterns

#71

Post by dfox » Sat, Jun 11, 2016, 11:06 AM UTC

aaron-santos wrote: post #66

dfox wrote: post #12

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.

I think I'm looking at an implementation of ifTrue[1], but it's a bit dense to someone who's not familiar with Smalltalk. Maybe you could walk me through it? [1] - http://git.savannah.gnu.org/gitweb/?p=smalltalk.git;a=blob;f...

That's the compiler part that optimizes the elegance away :). The interesting part is here [1], note that it will work without any support from the compiler.

[1] - http://git.savannah.gnu.org/gitweb/?p=smalltalk.git;a=blob;f... and http://git.savannah.gnu.org/gitweb/?p=smalltalk.git;a=blob;f...

Re: Anti-if: The Missing Patterns

#72

Post by aaron-santos » Sat, Jun 11, 2016, 9:35 PM UTC

dfox wrote: post #71

aaron-santos wrote: post #66

Earlier quoted context omitted.

I think I'm looking at an implementation of ifTrue[1], but it's a bit dense to someone who's not familiar with Smalltalk. Maybe you could walk me through it? [1] - http://git.savannah.gnu.org/gitweb/?p=smalltalk.git;a=blob;f...

That's the compiler part that optimizes the elegance away :). The interesting part is here [1], note that it will work without any support from the compiler. [1] - http://git.savannah.gnu.org/gitweb/?p=smalltalk.git;a=blob;f... and http://git.savannah.gnu.org/gitweb/?p=smalltalk.git;a=blob;f...

Much more straight forward. If I'm reading it correctly, True and False are subclasses of Boolean and each of which implements a complementary pair of ifTrue and ifFalse methods? Elegantly symmetric. :)

Re: Anti-if: The Missing Patterns

#73

Post by michaelmior » Sun, Jun 12, 2016, 8:10 PM UTC

mercer wrote: post #33

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.

If I'm doing an early return, I usually don't put the rest of the function inside the else case since I feel it creates an unnecessary level of indentation.

Re: Anti-if: The Missing Patterns

#74

Post by cle » Wed, Jun 15, 2016, 5:26 PM UTC

adrianratnapala wrote: post #30

cle wrote: post #23

Earlier quoted context omitted.

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.

Efficiency-wise I agree, but if I don't care about efficiency then I often prefer an if-chain (or better still, a switch-case). The point is that the desired mapping is known not just at compile time, but is explicitly known to the programmer. So it is clearer if it right there in the executable code rather than hidden away in some moving part (the mapping data structure).

Personally I don't like switch statements at all, especially the ones that require manual control flow management. I can vividly remember multiple bugs over the years caused by forgetting to add "break" to a switch statement.

Unless you're optimizing for performance (which is rare in my domain), control-flow statements are a smell and should be avoided. Each branch has some "implicit" state that is being fragmented and has to be manually managed by the programmer.