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

1–10 of 45 posts

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

#3

Post by alexfarran »

fortes wrote: post #2

One of the things I love about Google's Closure Compiler is that it takes care of these optimizations for you. If you want, you can write in an explicit readable style and still get any performance benefits.

But these are not performance optimisations.

Angus is making the case that functional techniques can be more concise and readable than procedural style control flow.

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

#4

Post by telemachos »

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.srcElement);
    }
Sure, it's very short in this written form. But for me to understand it, I need to think, roughly: evt retains its value, if it's a truthy value; otherwise give evt the value of window.event; if evt is a true value (now), return it and the value of evt.target - if that's truthy, or, if not, add in the value of evt.srcElement; oh, and by the way, if evt was not truthy initially in the return statement, bail out early (and return no value) since && only continues on if the initial value is true.

I'm not trying to be difficult, but I don't see that as miraculously more clear.

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

#5

Post by geuis »

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

Because when I look at "evt = evt || window.event", my mind has learned about the conditionals that each of these represent. Its analogous to phrases that mean different things in different contexts. "That guy has balls", for example.

So I look at it and I know that "if( evt )" is the same as "evt ? true:false" as "if( typeof evt !== 'undefined' ). I know that in the context of that statement, evt || window.event is saying "if evt exists, use that. if not, use window.event".

So the reason its confusing to people is they haven't learned all of the different things the shorter code means.

For me, after having spent many, many hours writing javascript I find the short form easier to understand and less tiring. Not only that, in raw numbers it just saves space.

Now, the other lesson I've learned over the years is that many times it is much better to start out writing in plain old "if" statements. Get the logic right, then reduce it down. There's nothing more annoying than trying to debug someone else's poorly written code.

And for god's sake, DOCUMENT!

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

#6

Post by BoppreH »

I'm a very young coder and loved the article, especially how it brings functional features to imperative languages.

But what if I write the entire company framework without a single conditional (including loops)? Are this alternatives to be used sparingly or as much as possible? Would you frown upon when you see it?

On a side note, I would love to never see a conditional again Even before learning functional programming I felt bad at every "if" and especially every "for" loop, but now I know why.

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

#7

Post by rue »

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…

The first line is perfectly fine to me, I read it "event is either given event or event from the window".

The second part is convoluted because of poor responsibility handling: ideally this function would never be called without some event present.

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

#8

Post by sesqu »

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

I've got to agree here. The short form is great for those ubiquitous "set if null" pieces of code, but you wouldn't want to use one for a complex conditional. The advantage comes in when you recognize the intent from the way it's formulated, and so don't have to trace the syntax. If your clause is something like "y%4==0 && (y%100!=0 || y%400==0)", you may want the long form, even for null y. I feel the example return statement is pushing it.

Additionally, it only works if you can trust that what is written is what is intended - which can be a problem with the gotchas in the truthiness system. If you aren't sure what type the input will have, you'll want the explicit checks, and if you don't have a helper function, those can drag on long enough to make it unreasonable to expect the reader to see the guard pattern.

All in all, I consider the short form a form of self-documenting code. If your readers don't find it easy to get used to, it becomes obfuscation. YMMV.

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

#9

Post by mrj »

BoppreH wrote: post #6

I'm a very young coder and loved the article, especially how it brings functional features to imperative languages. But what if I write the entire company framework without a single conditional (including loops)? Are this alternatives to be used sparingly or as much as possible? Would you frown upon when you see it? On a side note, I would love to never see a conditional again Even before learning functional programm…

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. Beware of excess cleverness. It would be far better to worry about the correctness of the code rather than optimizing for a meaningless benchmark (no ifs).

Post reply on HN