"Split or condition in if" refactoring
Tags: refactoring, beginners, webdev, programming
Published: 2022-10-29 10:51:30

---
title: '"Split or condition in if" refactoring'
published: true
description: Documenting the Split or condition in if refactoring
tags: 
- refactoring 
- beginners
- webdev
- programming
canonical_url: https://codesai.com/posts/2022/10/split-or-condition
cover_image: https://dev-to-uploads.s3.amazonaws.com/uploads/articles/jmr3gtfl68pgb5fzg58f.jpeg
# Use a ratio of 100:42 for best results.
---

We’d like to document a refactoring that we usually teach to teams we work with: the **Split or condition in if** refactoring.

<h2>Split or condition in if.</h2>

<h3>Motivation.</h3>

Sometimes we have nested conditionals that are branching depending on the same information. When an outer if condition contains an **or** which combines boolean expressions that check that information, splitting the **or** in the outer if may lead to opportunities to remove the rechecks in inner branching. This happens because having that **or** in the outer if forces us to check again the same information in an inner if condition.

Let’s see an example:

```javascript
export class Rover {
  // some code

  execute(command) {
    if (command === 'l' || command === 'r') {
      if (this.direction === "N") {
        if (command === 'r') {
          this.direction = "E";
        } else {
          this.direction = "W";
        }
      } else if (this.direction === "S") {
        if (command === 'r') {
          this.direction = "W";
        } else {
          this.direction = "E";
        }
      } else if (this.direction === "W") {
        if (command === 'r') {
          this.direction = "N";
        } else {
          this.direction = "S";
        }
      } else {
        if (command === 'r') {
          this.direction = "S";
        } else {
          this.direction = "N";
        }
      }
    } else {
      // some more code
    }
  }
}
```

Have a look at the `execute` method code of the `Rover` class (we’ve omitted some code for brevity). Notice how this code is branching twice depending on the value of the `command` variable. Using an **or** in the condition of the outer if, makes it necessary to recheck the `command` variable again in inner if conditions. This adds unnecessary nesting and duplication that can be easily removed if we first split the **or** in the outer if.
 
<h3>Mechanics.</h3>

Some IDEs have automated this refactoring, for instance, the [JetBrains](https://www.jetbrains.com/) family of IDEs. 
If you’re using one of JetBrains IDEs, you only need to place your cursor on the **or** condition and press `ALT+ENTER` to ask the IDE for possible context sensitive actions and select the **Split ‘||’ condition in ‘if’** from the pop up menu.

![Image Automated refactoring in WebStorm](https://dev-to-uploads.s3.amazonaws.com/uploads/articles/9cyv3pqjb4y0wpn61n7i.png "Automated refactoring in WebStorm")
<figcaption><strong>Automated refactoring in WebStorm.</strong></figcaption>

<br>

If your IDE does not have this refactoring automated, you can use the following mechanics to safely split the **or** condition in the if:

<a name="mechanics"></a> 

<ol>
    <li>
       Duplicate the if. <br>
       This step might be different depending on if there was initially an else or not. 
       <ul>
           <li>If there was an else, you’d need to add the duplicated code in an else if block.</li>
           <li>If there was no else, you can just duplicate the whole if besides the original one. </li>
       </ul>
       Note that this step may change the behaviour. The tests may not pass until you do the next step.
       </li>
    <li>
    Remove one clause of the <b>or</b> condition from one of the copies and the other clause of the or condition from the other copy. <br>
    At this point, run the tests to be sure that you haven’t accidentally modified the behaviour and the refactoring went ok.
    </li>
</ol>

![Image description](https://dev-to-uploads.s3.amazonaws.com/uploads/articles/pwjcvo0kxp8cgpkeg8tl.png)
<figcaption><strong>Refactoring mechanics when there’s no else.</strong></figcaption>

<br>

![Image description](https://dev-to-uploads.s3.amazonaws.com/uploads/articles/0vy0mqt0j4z0p9y27gbf.png)
<figcaption><strong>Refactoring mechanics when there’s an else.</strong></figcaption>

<br>

<h3>Related code smells.</h3>
Mainly *Duplicated Code* and *Complicated Boolean Expression*. 

**Splitting or condition in if** results in a code where is easier to remove both *Duplicated Code* and *Complicated Boolean Expression* smells, which in turn may unmask other smells. 

In the following video, we show how after applying this refactoring we can easily remove duplicated if conditions because they become obsolete (even though the refactoring is automated in WebStorm, we used the mechanics described above for demonstration purposes).

{% embed https://www.youtube.com/watch?v=Y3VQ5COBXgU %}

<h3>Related refactorings.</h3>

The inverse of this refactoring pattern is the **Combine ifs** refactoring pattern described by [Christian Clausen](https://twitter.com/thedrlambda) in his book [Five Lines of Code, How and when to refactor](https://www.manning.com/books/five-lines-of-code)

<h2>Conclusion.</h2>

We have described the **Split or condition in if** refactoring, and provided safe mechanics to perform it when it's not automated by your IDE. We hope this refactoring technique might be useful to you.

<h2>Acknowledgements.</h2>

I’d like to thank [Fran Reyes](https://twitter.com/fran_reyes) and [Rubén Díaz](https://twitter.com/rubendm23) for giving me feedback on the final draft of this post.