DEV Community

Do we even need if/else?

Muhammad Haseeb on December 07, 2021

Flow control is one of the first things we all learn as programmers. We are going to learn about some of the alternatives we have, that from my poi...

Read full post

JoelBonetR 🥇 • Dec 7 '21 • Edited

Yes of course we need if/else statements.

Using ternary operator you simply chain if - else if statements the bad way under the hood which is not always the best option. It is good for a single comparison with a fallback or 2 as much.

foo === 'x' ? doSomething() : foo === 'z' ? doSomethingElse() : fallback()

equals:

if (foo === 'x') {
  doSomething();  
} else {
  if (foo === 'z') {
    doSomethingElse();
  } else {
    fallback();
  }
}

you can quickly spot the problem here, specially when chaining more options.
On the other hand if you only need to handle an action if something evaluates to true, there's no point on using a ternary:

if (foo === true) 
  doWhatever();

cannot be translated into a ternary, simply because you don't need to do a different thing in case the expression evaluates to false, it would be somewhat weird (and wrong) to do it like:

foo === true ? doWhatever : '';

Using switch case you only provide an action, also not valid for every operation. Several times you need to ensure multiple conditions. Simple example: needing to check if a user has a paid account and then checking if this account is a premium account or a regular paid one, what you do? chaining switch statements? that would be a mess. Chaining a ternary after the switch is also not an option for the last example in ternary concerns.

*As side-note, switch statements are harder to optimise by the JIT as well, in comparison with if-else statements.

To use the Nullish coalescing operator ?? operator you don't even need an Object, i.e.

const foo = null ?? 'default string';

is valid as well but as you can imagine, that does not fit for any case.

So yes, we still need if else statements and they do the job pretty well in many cases.

Peter Vivo • Dec 7 '21 • Edited

Depend on format, imho much better readable than if plus ternary give a result, do not need use let or var

const result = foo === 'x'
  ? doSomething() 
  : foo === 'z' 
    ? doSomethingElse() 
    : fallback()
  ;

JoelBonetR 🥇 • Dec 8 '21 • Edited

I can't understand why y'all focus on readability in the first hand. Even Uncle Bob told us that the first half of a Dev's job is to make things work and the second half is to make it clean and readable.
You need to check first that your code covers the use cases and it's right (in the functional sense) and then you can re-write it on a more readable way (if any).

I'll set a funny working example on how to hash a string in JS using the Bitwise OR assignment in combination with the Left Shift Operator :

String.prototype.hash = function () {
  'use strict';
  var h = 0, i;
  if (this.length === 0) return h;
  for (i = 0; i < this.length; i++) {
    h = (h << 5) - h + this.charCodeAt(i);
    h |= 0;
  }
  return h;
}

now you can do myString.hash(). Enjoy.
If you're too afraid of ES releasing a hash() method you can use it as function as well

hash(str) { 
  'use strict';
  var h = 0, i;
  if (this.length === 0) return h;
  for (i = 0; i < this.length; i++) {
    h = (h << 5) - h + this.charCodeAt(i);
    h |= 0;
  }
  return h;
}

and call it like myString = hash(myString)

It works, i states for index and h states for hash.
You can change the variable names if you want to "index" and "hash" but can it be more readable than that? Let's let this question on air so you can answer with your ideas.

My guess is that unless you know how those operators work, you'll not fully understand it, on the other hand if you know'em, it will be obvious to you.

Peter Vivo • Dec 8 '21 • Edited

I think readability help take look our code even few month later.

Imho your hash algorythm looks like this:

const hash = str => [...str]
  .map(chr => chr.charCodeAt(0))
  .reduce((acu, code) => ((acu << 5) - acu + code) | 0, 0)
  ;

JoelBonetR 🥇 • Dec 8 '21 • Edited

That's beautiful, and it can be provided as string method like:

String.prototype.hash = function () {
  return [...this]
  .map(chr => chr.charCodeAt(0))
  .reduce((acu, code) => ((acu << 5) - acu + code) | 0, 0)
}

This last one adds the requirement of understanding map and reduce and the one above the knowledge of basic if operator and for loop

That's just what we were talking about. Either the one in my post above or yours reduced example will be easy to understand if you know the operands but hard a.f. if you don't.

Readability is objective till some point where it turns subjective (by the knowledge and experience PoV) and that's the main reason of this cyclic discussions imo 😆

Someone whith basic or zero understanding on map would say yours is shit and someone with no knowledge of bitwise operators would complain of mine as well. The result in terms of readability can vary but none of those examples have a single thing wrong in readability terms, it has more or less lines of code (which is never equal to readability) and different operators or functions to reach the same. Which is more readable? Some will say 1 some will say 2. The important thing here is that both provide (unless I miss something) the exact same result for a same entry value.

Peter Vivo • Dec 9 '21

That is the reason to know more about .map .filter .find and .reduce functionality in js. After basic one like if/else, for, while, switch. These functionality is lead to functional programming direction.

Any way

String.prototype.hash =

means you declare one global dependency on your code. I think much better to forget this type of work. Because this declaration influence your team whole application.

JoelBonetR 🥇 • Dec 9 '21

It will be available just when you import the file containing it, not less not more. It just depends on the project architecture. The only concern about setting string (or other data structure) methods like this is the possibility of ES adding a method with the same name and thus having to refactor it everywhere it's used (or deleting it if it's provided along the language)

JoelBonetR 🥇 • Dec 8 '21 • Edited

Having a chained ternary is not always wrong. Chaining them more than 2 or 3 times are usually wrong because you'll rely on checks that are dependant on each other and you'll probably need different chained ternary blocks to reach the expected use cases so it's better to use if/else but

foo === "x" ? doSomething : foo === "z" ? doSomethingElse : fallback;

There's nothing wrong here as long as this covers your use cases properly. If you don't need the fallback then this is wrong but if this is just what you need then go ahead with that, we should be fine.

const otherCases = foo => (foo === "z" ? doSomethingElse : fallback);

const example = foo === "x" ? doSomething : otherCases(foo);

example(value)();

This is supposed to be equivalent to the code above but instead you add a function declaration and a variable to reach... pretty much the same?
This is absurd. An extreme lack of knowledge about logic gates and inefficient way of working just because "you like how it looks".

Then here

foo ? doSomething() : undefined;

Why should you state "undefined" just because foo is falsy?
You are not even setting this value into a variable to check later (it can be ok depending on the use case). instead you're just saying:

if (foo) doSomething();
else undefined;

The question now is... undefined what? What's the point? What should we do with this undefined?

Again your starter point is "I like how it looks" not an understanding on how things work below.

Aschwin Wesselius • Dec 7 '21

Thanks for the examples in JavaScript.

I thought you were going to show the use of monads in JavaScript, LOL. Because every time I see a post about omitting if/else, switches etc. they introduce the usage of monads. Which are maybe better, computation and logic wise, but a hard topic to master.

Phantz • Dec 7 '21

The irony there being, to implement monadic binding to abstract away branching, you need branching in the first place :)

Since we did bring up monads, the entirety of category theory must now follow. Selective applicative functors showcase the "branch"ing effect abstracted away into the functor. Which is ofcourse a realization of strength and costrength applied elegantly. The application itself, of this abstract concept in practice, requires laziness, but that's uninteresting.

I kid, I kid. Not "kid" in the sense that everything I said above is nonsense (it isn't), but rather, in the sense that all of it should be nonsense :)

(Haskellers, please don't kill me with your arrows)
(Non-Haskellers, please don't crucify me for unnecessarily bringing up category theory)

Gaurav Chandra • Dec 8 '21

Although this is fine for concise code but it is a nightmare when it comes to readibility. Not every dev is on the same level and it is imperitive that the code be readable. With all these bundlers in js ecosystem, this code will anyways be coompacted.

We should not forget that right now humans are writing the code and not machines so humans need to understand that part. The code anyways boils down to machine code at the time of compilation/transpilation. And I completely agree with @joelbonetr .