LOL
I guess technically, if statements could have been omitted in this example (though there’d still be a conditional present).

function wow(arg){
  var o = {
    dog: "LOVELY",
    cat: "CUTE"
  };
  return o[arg] || "gimme an animal";
}

wow("cat");

Cool point. In cases like this, I often forgo the else altogether because of the return statements.

function wow(arg){

  if(arg === "dog") return "LOVELY";

  if(arg === "cat") return "CUTE";

  return "gimme an animal";
}

wow("cat");

Still, your point about understanding the why behind what we write is an important one. Thanks for sharing.

Another blind gospel: braces around if-statements imply that people don't understand what braces do (they turn a group of statements into a single statement). So rules like "always put braces around the body of your if-statement" get it backwards, it'd be like wrapping every value in an array, because maybe you'll want more than one of them, someday.

This brings us to the the three-brace rule: if you're going to make me put one brace where I don't need it, then I'm going to add two more.

function wow(arg) {{{
  if(arg === "dog") {{{
    return "LOVELY"
  }}} else if(arg === "cat") {{{
    return "CUTE"
  }}} else {{{
    return "gimme an animal"
  }}}
}}}
console.log(wow("cat"))           // => CUTE
console.log(wow("dog"))           // => LOVELY
console.log(wow("hat-log"))       // => gimme an animal

Now, in people's defense, JavaScript's syntax is terrible, it's absurd that this works (when it would be so much more useful to have toplevel objects), and given that it works, it's absurd that you can't drop the braces around function bodies.

And the other super obnoxious mostly un-understood rule: littering semicolons all over the code. Literally after every line that they can, rather than before the ones that cause the problems. It's especially misguided b/c it masks the actual problem lines, and it gives a false implication that omitting the semicolon would mean it continues on the next line. But that isn't true, JS doesn't need a semicolon to terminate the line, only to terminate it early. The reason you stick them at the end is b/c sometimes the next line says "oh hey... Imma tag along with the previous line", so with this dumb rule, every line has to guard against an aggressive next line.

log = text => { console.log("logged: " + text); return log }
log("loggin stuffs")

// and now for some math
(2+2)
(3+3)

Only use conditional jumps...wait! xD

Thanks for the write-up. This kinda reminds me of that beginner's guide to shell scripting article that opened our minds to the fact that when we use if brackets in bash we're actually using test ;).

While everyone is busy pointing out flaws in if~else, It seems that I don't get the point of this post.

Fabio Russo (or Anyone), can you please give me one edge case when knowing that there is no "else if" would actually create any noticeable difference in any possible way.

If it just happens to be a trivia, we can extend this argument to anything in Javascript.

Like there is no Javascript but just machine code :?

Then why is it there in the language? To put in other words, where does it make sense to use an if-else statement?

This is a good point, and I think we could write some much longer posts on some of these practices.

I appreciate how this points out how important the "why" is of many of these patterns and practices.

I've been developing in JS since nearly the beginning and many of these "best practices", that are somehow still mainstream, are for problems that no longer exist.

Since people often don't know why we did them, they continue to persist them because all the Sr. Devs told them to years ago.

The "why" is so important to know.

Good point, buy maybe you should change your example so you don't use the return clause.

I feel like refactoring your example to:

function wow(arg){
  if (arg === "dog") return "LOVELY";
  if (arg === "cat") return "CUTE";

  return "gimme an animal";
}

"there is a golden rule"... Sometimes I sacrifice efficiency for readability, sometimes I do the opposite. To say one size fits all is arrogant, narrow minded and not teaching good practices. There should be a good reason to do everything we do, even if it is not the most appropriate it can still be the correct choice for that instance