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

No ifs...alternatives to statement branching in JavaScript

javascriptweblog.wordpress.com

Post reply on HN
Print view View original

31–40 of 45 posts

Re: No ifs...alternatives to statement branching in JavaScript

#31

Post by gruseom »

geuis wrote: post #5
telemachos wrote: post #4

Dislike of if confuses me. People claim to find conditions wordy or confusing. I don't find conditions particularly difficult to follow, but I have a question from the other side: when you use && and || as logic gates, don't you (in your mind) translate them back into conditions anyhow? Here's his first example without if: function getEventTarget(evt) { evt = evt || window.event; return evt && (evt.target || evt.srcE…

Look at it like this. I am a developer who prefers the terse code compared to the longer if() variety. I've been doing this long enough that its is easier, clearer, and faster for me to understand the "evt = evt || window.event" than it is to trace through all of those if() statements. I used to be the opposite, I couldn't understand the short form or how it worked. Ternaries confused the hell out of me for a while.…

And for god's sake, DOCUMENT!

What clarity would documentation add to this example?

Re: No ifs...alternatives to statement branching in JavaScript

#32

Post by angusC »

Hi - I 'm the author of this post. A few comments:

1) It wasn't my intention to create a holy war. There are good arguments on both sides. I use ifs and fors in my own code and will continue to do so.

2) Over the years I have developed a distaste for the overuse of statement branching - I find it distracting and I feel it works against readability.

3) I wanted to catalog a bunch of (mostly well known) alternatives to present as a coding strategy

4) I realize that not everyone likes such terseness of style and what is clear syntax to one person can be undecipherable to the next.

5) Use what ever works best for you and your team

(Notice how procedural this comment was :-) )

Re: No ifs...alternatives to statement branching in JavaScript

#33

Post by mrj »

BoppreH wrote: post #20
mrj wrote: post #9

Earlier quoted context omitted.

What if you did? Would it be a better framework? Would anybody care at all? I doubt it. This a code style and if you like it, then maybe you use the parts you want. But "micro branching" is still branching and it makes little difference how you do it (except the nod to performance concerns towards the end). Thinking about code style and readability is useful and good, but this is by no means a common way to code. Bew…

It would not be for cleverness, much less for optimization (is it even faster?) For some reason every time I see a condition I cringe mentally. There's something in a "for" loop that makes me uncomfortable and god, using "map", "filter" and micro branching would help a lot. I'm just thinking of what I would like to see and checking it against the opinion of others.

Maybe it's a coding style that suits you then. That's cool.

I just caution against putting it in such simple terms. I hate it when I read code by somebody who latched on to the latest trend and then ruthlessly bent their style to match the new way, whether it made sense or not.

As for performance, it would have to be tested. In some languages with first-class closures, a lot of code like the examples might seriously strain the garbage collector (if present). There might be a ton of young objects to clean up, all the time. That was my only thought on it.

Re: No ifs...alternatives to statement branching in JavaScript

#34

Post by BoppreH »

ori_b wrote: post #29
BoppreH wrote: post #23

Earlier quoted context omitted.

Branches too. The only conditionals I've seen in functional programming are equivalent to the ternary operator. Unless I'm absurdly wrong, which can happen.

I think codesearch can answer you: http://www.google.com/codesearch?q=if+lang%3Ahaskell

"if"s in Haskell work exactly like the ternary operators, just as I said. I was using the article's differentiation of "branching" and "microbranching" and stating that I haven't seen the former in functional languages.

The link provided doesn't contradict any of this, actually it does quite the opposite.

Re: No ifs...alternatives to statement branching in JavaScript

#35

Post by BoppreH »

davidw wrote: post #26
BoppreH wrote: post #23

Earlier quoted context omitted.

Branches too. The only conditionals I've seen in functional programming are equivalent to the ternary operator. Unless I'm absurdly wrong, which can happen.

The program still branches (decides which code path to follow) - it just does it with a different mechanism, for instance pattern matching.

Yes, pattern matching fits the bill, thanks.

Re: No ifs...alternatives to statement branching in JavaScript

#36

Post by scott_s »

gruseom wrote: post #30
scott_s wrote: post #16

Earlier quoted context omitted.

Simply, no. I prefer to think in boolean expressions rather than sequences of statements. Personally, I'd further reduce it to (assuming there's no JavaScript subtleties I'm missing here; in C/C++ this would have the same semantics): function getEventTarget(evt) { return (evt || window.event) && (evt.target || evt.srcElement); } A boolean expression is straight-up math, and I've been trained to reason about that. Wit…

But that crashes on null in all three languages, no? (i.e. if evt is null and window.event is non-null.) I suppose you could do this: function getEventTarget(evt) { return (evt || (evt = window.event)) && (evt.target || evt.srcElement); } But that's probably more trouble than it's worth. Anyway, I agree with you in preferring expressions to statements on the whole. It's hard to imagine why anyone would prefer the mor…

In C/C++, evt could never be null because it would have to be a stack allocated object or a reference. (We're not dereferencing a pointer.)

Re: No ifs...alternatives to statement branching in JavaScript

#37

Post by gruseom »

scott_s wrote: post #36
gruseom wrote: post #30

Earlier quoted context omitted.

But that crashes on null in all three languages, no? (i.e. if evt is null and window.event is non-null.) I suppose you could do this: function getEventTarget(evt) { return (evt || (evt = window.event)) && (evt.target || evt.srcElement); } But that's probably more trouble than it's worth. Anyway, I agree with you in preferring expressions to statements on the whole. It's hard to imagine why anyone would prefer the mor…

In C/C++, evt could never be null because it would have to be a stack allocated object or a reference. (We're not dereferencing a pointer.)

Gotcha. It's been a while!

Re: No ifs...alternatives to statement branching in JavaScript

#39

Post by konad »

gruseom wrote: post #31
geuis wrote: post #5

Earlier quoted context omitted.

Look at it like this. I am a developer who prefers the terse code compared to the longer if() variety. I've been doing this long enough that its is easier, clearer, and faster for me to understand the "evt = evt || window.event" than it is to trace through all of those if() statements. I used to be the opposite, I couldn't understand the short form or how it worked. Ternaries confused the hell out of me for a while.…

And for god's sake, DOCUMENT! What clarity would documentation add to this example?

// I don't like the keyword "if" so I'm hiding it with && and || because I haven't thought deep enough about a better way of structuring my code

// TODO think harder

Re: No ifs...alternatives to statement branching in JavaScript

#40

Post by gruseom »

konad wrote: post #39
gruseom wrote: post #31

Earlier quoted context omitted.

And for god's sake, DOCUMENT! What clarity would documentation add to this example?

// I don't like the keyword "if" so I'm hiding it with && and || because I haven't thought deep enough about a better way of structuring my code // TODO think harder

I'm guessing you must be joking?
Post reply on HN