Month: September 2014

Refactoring Deeply Nested if Statements

Deeply nested if statements are a pain to read and maintain, so you should try to avoid them as much as possible. Here are a couple of suggestions on how reduce deeply nested if statements to a more manageable size.

Most of these suggestions can be applied to most languages that have the if statement, at least most object oriented or procedural languages. But my main focus when writing this were Java and PHP.

Early Return

Early returns should be used a lot more often by pretty much everybody. It’s one of the easiest ways to avoid or reduce deeply nested if statements and one of the first things I would look for when refactoring code.

The main idea is that when checking a value, the negative case is moved up-front, the error handled, and then the method is exited:

boolean test1 = ...;
if (test1) {
    boolean test2 = ...;
    if(test2) {
        boolean test3 = ...;
        if(test3) {
            // do the stuff
        } else {
            // some error, handle it
        }
    } else {
        // something else
    }
} else {
    // some other error, handle it
}
return;

Here, you can move the checks to the top of the method and remove three levels of nested if statements:

boolean test1 = ...;
if(!test1) {
    // some other error, handle it
    return;
}
boolean test2 = ...;
if(!test2) {
    // something else
    return;
}
boolean test3 = ...;
if(!test3) {
    // some error, handle it
    return;
}
// do the stuff
return;

Refactoring Simple Boolean Checks in if-Statements

How to refactor simple boolean checks in if statements and avoid bad practices.
This is the first post out of a number of posts dealing with refactoring. This particular post is aimed at beginners, but further posts will contain somewhat more advanced concepts.
The concepts presented here can be used in a lot of programming languages, but the article is written with Java, PHP, and JavaScript in mind.
For one-liners, the general formating will look like this: