Today I Learned - Rocky Kev

TIL removing ELSE statements to write clearer code

POSTED ON:

TAGS: javascript webdev

I've been thinking about this dogma for years.

“Programs are meant to be read by humans and only incidentally for computers to execute.” - Donald Knuth, The Art of Computer Programming.

I hate Nestled If statements

I think we can all agree -- nestled if statements suck!


function suckyCarChecker(isCar, howManyWheels) {

  if (isCar) {
    if (howManyWheels === 1) {
      return "You're a unicycle!";
    } else if (howManyWheels === 2) {
      return "You're a bike!";
    } else if (howManyWheels === 3) {
      return "You're a trike thing?";
    } else if (howManyWheels === 4) {
      return "You're a car or truck";
    } else if (howManyWheels > 4) {
      return "You're tractor trailer or something else?";
    } else {
      return "I don't think you have wheels.";
    }
  } else {
    return "You're not a car";
  }
}

NOBODY: "This code is soooo readable!" 🤢

And if you like that code above, then don't read the rest. It'll just annoy you.

Being a better coder by not using Else

Some people feel very strongly about not using Else. Like "Write better code and be a better programmer by NEVER USING ELSE statements"

PROTIP: Like Drama? If you ever see the word NEVER, read the comments and watch a bunch of nerds fight. Because of course, take the advice with a grain of salt. You will always have edge-cases where you HAVE TO break the rules.

There'a few ways to solve the 'don't use Else' dogma, in no particular order. It's also not a definite list.

  1. Guard Clauses (reverse the logic)

Also called early exits at my job.

It looks like this:

 if (!isCar) {
  return "You're not a car";
 }
  1. Helper functions

Abstract it to it's own function.

It's good practice to extract the logic of the conditions in small functions that allow greater readability of the code (and, of course, to find bugs in them) since the responsibility of evaluating the condition is being delegated to a specific function.

Via https://betterprogramming.pub/refactoring-guard-clauses-2ceeaa1a9da

It doesn't solve the else completely, but it moves the logic to some place more manageable.


function suckyCarChecker(isCar, wheels) {
  if (!isCar) {
    return "You're not a car";
  }

  return howManyWheels(wheels);
}

function howManyWheels(wheelCount) {

    if (wheelCount === 1) {
      return "You're a unicycle!";
    } else if (wheelCount === 2) {
      return "You're a bike!";
    } else if (wheelCount === 3) {
      return "You're a trike thing?";
    } else if (wheelCount === 4) {
      return "You're a car or truck";
    } else if (wheelCount > 4) {
      return "You're tractor trailer or something else?";
    }
}
  1. Using data objects and map/filter/reduce

Your goal is to return a string.
Why not turn that whole if statement into a object?

const wheelCount = {
  {
    wheels: 1,
    text: "You're a unicycle!";
  },
  ...
}

Then you can match the wheelCount['wheels'] and output the text using some modern javascript.
(map, reduce, filter)[https://medium.com/poka-techblog/simplify-your-javascript-use-map-reduce-and-filter-bd02c593cc2d]

Heck, some extreme programmers don't even want to use conditionals at all!

  1. Sometimes you gotta use that switch statement

Related TILs

Tagged: javascript

TIL what is npm Script

Despite their high usage they are not particularly well optimized and add about 400ms of overhead. In this article we were able to bring that down to ~22ms.

TIL fancy methods to transform Javascript Objects

You can use Object.entries(), Object.keys(), Object.fromEntries()...

TIL how to hide your JS code

ONE THING TO NOTE: Encrypting a script is stronger than obfuscation, both methods are still not adequate to protect secret content. Honestly, I don't think it's worth it on a production site, and instead just go with pure server-side if you want security. But it's fascinating.