Thinking functionally has opened my mind about programming. It has given me a greater depth of understanding of code. It has also led me on a quest in which I found myself questioning many of the core features of the language.

I have recently been questioning the if statement itself.

Having written an entire application completely void of a single if statement, I have found if to be optional.

If you are unfamiliar with functional programming this probably sounds like the rantings of a mad man, but stick with me a bit and allow me to explain.

Learning multiple ways to solve the same problem amplifies your mental toolkit by magnitudes.

First, meet the if statement replacement, the ternary operator:

condition ? expr1 : expr2

Functional programming has taught me to write small functions like this:(don’t yell at me for not currying, that’s for another article)

const add = (x, y) => x + y

The if statement doesn’t fit into this type of function, but the ternary operator does!

const isGreaterThan5 = x => x > 5 ? 'Yep' : 'Nope'

Soon I began to find almost every instance of an if statement could be replaced with an equivalent ternary operation.

// typical code you might stumble upon
function saveCustomer(customer) {
  if (isCustomerValid(customer)) {
    database.save(customer)
  } else {
    alert('customer is invalid')
  }
}

// ternary equivalent
function saveCustomer(customer) {
  return isCustomerValid(customer)
    ? database.save(customer)
    : alert('customer is invalid')
}

// ES6 style
const saveCustomer = customer =>
  isCustomerValid(customer)
    ? database.save(customer)
    : alert('customer is invalid')

Then I started to think how the ternary operator could fit into an else-if statement. I was able to do this with a nested ternary, but it was really messy and not easy to understand.

// old school else-if
function customerValidation(customer) {
  if (!customer.email) {
    return error('email is require')
  } else if (!customer.login) {
    return error('login is required')
  } else if (!customer.name) {
    return error('name is required')
  } else {
    return customer
  }
}

// ES6 style custom formatted ternary magic
const customerValidation = customer =>
  !customer.email   ? error('email is required')
  : !customer.login ? error('login is required')
  : !customer.name  ? error('name is required')
                    : customer

Now you can clearly see all the conditions defined on the left hand side and the values returned on the right side.

Even though it is possible to replace every if statement with a ternary operator, I am not saying you should do so. This is just another tool for you to use and consider.

But Why?

Name: Rethinking JavaScript: The if statement
Rating: 4.9 (2038 reviews)
Author: joelnet

We are not just eliminating the if, but also eliminating statements and blocks in favor of expressions. While there is nothing "functional" about doing this. Learning to code without statements or blocks is one of multiple pre-functional steps that will allow you to write more functional code.

A note on readability

There is a direct correlation between "readability" and "exposure".

An example of this is seeing a new word for the first time like 'perfidious'. Having never seen it, you might have to read each letter and sound it out in your head. You might also prefer to use it's synonym 'disloyal', which you feel is "easier". After all, 'disloyal' is the word that you grew up with and have been using your whole life.

But after you have sounded the word out a couple times, know the definition and started using it in a few sentences, it will start to become second nature. You can now quickly glace at the word 'perfidious', pausing no longer than you would when reading other words as it becomes more and more familiar with time.

And now that you have added more words to your vocabulary, you can more effectively communicate because you have more tools to pull from your linguistic toolbox.

The structure of this ternary also mimics the structure of Ramda's cond which also has the conditions on the left and the actions on the right, so using one should make you more familiar with the other.

var fn = R.cond([
  [R.equals(0),   R.always('water freezes at 0°C')],
  [R.equals(100), R.always('water boils at 100°C')],
  [R.T,           temp => 'nothing special happens at ' + temp + '°C']
]);
fn(0); //=> 'water freezes at 0°C'
fn(50); //=> 'nothing special happens at 50°C'
fn(100); //=> 'water boils at 100°C'

Even Mozilla suggests:

By breaking the ternary onto multiple lines and making use of extra whitespace, the ternary operator can be used to very cleanly replace a lengthy series of if/else statements. This provides a syntactically light way of expressing the same logic:

I promise, readability will come with time.

End

This Rethinking JavaScript article is just one in a series. More to come in the near future!

I would love to hear your feedback and thoughts on how you would rethink theif statement. Do you have a scenario where you are unsure how this will work? Tell me, let me know!

Continue to Part 2 Rethinking JavaScript: Death of the For Loop.

I know it’s a small thing, but it makes my day when I get those follow notifications here and Twitter (@joelnet). Or if you think I’m full of shit, tell me in the comments below.
Cheers!

Originally posted here: https://hackernoon.com/rethinking-javascript-the-if-statement-b158a61cd6cb