DEV Community

Discussion on: Optimize the use of if-else, you need a better selective structure!

View post
Collapse
 
deozza profile image
Edenn Touitou • • Edited

Simple thing to reduce the size and complexity of if-else loops : fail-fast.

You sort the conditions by their complexities and return each time. For example in place of writing :

if(response === 200) {

// ALL your business logic

}else if (response === 400){
}
else if(response === 403){
}
else if(response === 401){
}
Enter fullscreen mode Exit fullscreen mode

Write something more like this :

if (response === 401){
return
}

if(response === 403) {
return
}

if(response === 400) {
return
}

//BUSINESS LOGIC

return
Enter fullscreen mode Exit fullscreen mode

Code is less cluttered by unnecessary else-if and you understand better the goal of the function

Collapse
 
thethirdrace profile image
TheThirdRace • • Edited

Unpopular opinion: this structure is far from ideal for readability.

Before going any further, I want to mention that I 100% agree with the fail-fast methodology. You should always do that, but not at the cost of readability.

1 - Alphabetical order

Response statuses, or any code, should be in alphabetical order.

It's much easier to read when the codes are top -> down in a chronological order.

Trying to optimize execution time is totally pointless, you're not even gonna save 1 ms while going against any logical search pattern with your eyes...

If I need to CTRL + F or CMD + F to figure out which status is where, readability is 0%.

2 - Line indentation

Indentation improves readability a thousand fold.

Flattening your structure means you now have an implicit relationship with your ifs.

Given your eyes will scan top -> down first, then left -> right (assuming english), the if / else if / else pattern will give you immediate and explicit relationships between all the elements of your code.

3 - Multiple returns

Oh my, the most unpopular opinion ever...

Using multiple return in a function will force you to scan the whole code to figure out the exit points. The burden is put on the reader to map every single outcome by himself.

When using multiple return, every single if becomes a potential trap the dev could fall into and make a mistake. You absolutely need to scan all the code to figure out if the next block of code will be executed or not because at any point the eject button could be pressed.

If you use only 1 entry point and 1 exit point, you know by simply scanning top -> down that the next block of code will always be executed. All you have to do is follow indentation, the if / else if / else brackets and the whole outcome map will be laid out for you. You don't have to do any mental gymnastic, it's simple and you should very rarely make mistakes.

4 - Eye pattern

Just take a glance at those 2 patterns:

// Pattern A
xx (xxxxxx xxx xxx){
  xxxxxxxx xxxx xxxxx
}

xx (xxxxxx xxx xxx){
  xxxxxxxx xxxx xxxxx
}

xx (xxxxxx xxx xxx){
  xxxxxxxx xxxx xxxxx
}

xxxx xxxxxxx x xxxxxx
xxxx xxxxxxx x xxxxxx
xxxx xxxxxxx x xxxxxx

xxxxxxx
Enter fullscreen mode Exit fullscreen mode

Or

// Pattern B
xx (xxxxxx xxx xxx) {
  xxxxxxxx xxxx xxxxx
} xxxx xx (xxxxx xxx xxx) {
  xxxxxxxx xxxx xxxxx  
} xxxx xx (xxxxx xxx xxx) {
  xxxxxxxx xxxx xxxxx  
} xxxx {
  xxxxxxxx xxxx xxxxx  
  xxxx xxxxxxx x xxxxxx
  xxxx xxxxxxx x xxxxxx
  xxxx xxxxxxx x xxxxxx
}

xxxxxxx
Enter fullscreen mode Exit fullscreen mode

At a glance, can you tell me with 100% certainty that conditions in pattern A are mutually exclusive?

How about in pattern B?

With pattern A, you simply cannot know without any doubt the nature of those conditions. Maybe they're mutually exclusive, maybe they all apply, maybe it's anything in between.

With pattern B, you don't even have to know what's written, just look at the brackets and the indentation and you already know those conditions are mutually exclusive. Even after replacing every single letter by x, the meaning is still there and the pattern is still obvious.

Conclusion

I know a lot of people will go completely banana against this opinion. It's fine, I'm used to it.

All I'm gonna say is people need to take into account accessibility and readability. Both of which won't prevent you from failing fast/early and they won't impact performance in the slightest. There's really no reason to not account for them.

Collapse
 
akarachen profile image
AkaraChen •

This is indeed very useful, I forgot when I was writing it, I will add it in the next article revision

Collapse
 
hilleer profile image
Daniel Hillmann •

THANK YOU. I wanted to write this exact thing but you came first