This content originally appeared on Go Make Things and was authored by Go Make Things
This week in the Frontend Horse Discord, my friend Ben Myers shared a really neat technique for making complex if checks more readable that I liked quite a bit, and wanted to share with you today.
Let’s dig in!
A complex check
Let’s imagine you have some function that checks if a creature isMagical().
Certain types of creatures (unicorns and elves) are inherently magical. Others, like humans and gnomes aren’t generally magical but can be if they have certain tools.
Our function looks like this.
/**
* Is a creature magical?
* @param {String} creature The type of creature
* @param {String} tool The magical tool they have, if any
* @return {Boolean} If true, they're magical
*/
function isMagical (creature, tool) {
// If the creature is inherently magical
// OR if they're not but use a magical item
// return true
if (creature === 'unicorn' || creature === 'elf' || (creature === 'gnome' && tool === 'alchemy') || (creature === 'human' && tool === 'wand')) {
return true;
}
// Otherwise return false
return false;
}
As you can see, that’s not particularly easy to read and reason about because of all the or operators (||) inside the if statement. Some also include an and operator (&&), making things more confusing.
A common way to rewrite this
One easy fix is to break each check into it’s own line, like this…
/**
* Is a creature magical?
* @param {String} creature The type of creature
* @param {String} tool The magical tool they have, if any
* @return {Boolean} If true, they're magical
*/
function isMagical (creature, tool) {
// If the creature is inherently magical
// OR if they're not but use a magical item
// return true
if (
creature === 'unicorn' ||
creature === 'elf' ||
(creature === 'gnome' && tool === 'alchemy') ||
(creature === 'human' && tool === 'wand')
) {
return true;
}
// Otherwise return false
return false;
}
Already, that’s much more readable. There’s still an opportunity to mess something up, like forgetting one of the or operators or a parentheses, but it’s much easier to glance at and see your checks.
Assigning checks to variables
Ben’s suggestion, which I quite rather liked, was to assign each check to it’s own unique variable. Then, you can use those in your if statement instead.
/**
* Is a creature magical?
* @param {String} creature The type of creature
* @param {String} tool The magical tool they have, if any
* @return {Boolean} If true, they're magical
*/
function isMagical (creature, tool) {
// Checks
let isUnicorn = creature === 'unicorn';
let isElf = creature === 'elf';
let isMagicGnome = creature === 'gnome' && tool === 'alchemy';
let isMagicHuman = creature === 'human' && tool === 'wand';
// If the creature is magical return true
// Otherwise return false
if (isUnicorn || isElf || isMagicGnome || isMagicHuman) return true;
return false;
}
As you can see, this makes it far easier to read each unique check, and to see how they all work together as part of the broader functional logic.
It also makes it far easier to update your checks in the future.
Bonus points: naming things
One of the other things that came up in the discussion on the Frontend Horse Discord was around naming things.
As a good rule of thumb, things that return a boolean (true/false) value should start with is* or *has. Functions that do things should start with a verb that describes what they do, like get*() or add*().
If you want to learn more about my approach to naming things, I’ve written a full article on it here.
⏰ Last Chance! A new session of the Vanilla JS Academy starts on Monday. Join today and get 30% off registration.
This content originally appeared on Go Make Things and was authored by Go Make Things
Go Make Things | Sciencx (2023-03-30T14:30:00+00:00) Breaking chained if checks into smaller pieces in JavaScript. Retrieved from https://www.scien.cx/2023/03/30/breaking-chained-if-checks-into-smaller-pieces-in-javascript/
Please log in to upload a file.
There are no updates yet.
Click the Upload button above to add an update.