Keep indentation level low [duplicate]

Question

I hear a lot that you should not write functions larger than one screen size, that you should extract things into functions if you call things very often and all these coding guidelines. One of them is also keep your indentation level low. Some people told me even I should max indent 4 times.

But in every day programming it keeps happening that I need O(n^2) or O(n^3) loops with some flow control, which creates out of nowhere 7 or 8 layers of indentation...

Are there any good ways to avoid that? One problem is, if you try to avoid complex if/else statement nesting I tend to do this in one row which can look very terrible and be unreadable and not very easy to maintain.

Answer 1

Inverted If

Most developers think in terms of nested logic. It's difficult for them to invert their logic to reduce nesting. Deeply nested code is more difficult to read, and to reduce nesting you often have to invert your logic.

When a programmer writes code they write in a logical tree structure like this.

 bool function publish(Document doc)
 {
    if(doc != null)
    {
        if(doc.status == "finished")
        {
            doc.print();
            if(doc.locked)
            {
                doc.unlock();
            }

            return true;
        }

        return false;
    }

    return false;
 }

The above is logically correct, but it introduces indents that make it difficult to maintain in the future. It's difficult, because additional logic will require deeper blocks. The deeper it gets the more likely a bug will be introduced.

By inverting your if statements and combining them you can reduce the nesting.

 bool function publish(Document doc)
 {
    if(doc == null || doc.status != "finished")
    {
        return false
    }

    doc.print();

    if(!doc.locked)
    {
        return true;
    }

    doc.unlock();

    return true;
 }

This inverted kind of logic keeps all the function operations within the first indented block and if statements are only used to terminate the function.

Split Loop And Work

Don't perform your work operations inside a loop block. Separate iteration from the task itself. This creates functions of single purpose.

Take this example

function void PrintDocuments(List<Document> pDocuments)
{
    for(int doc=0; doc < pDocuments.Count; doc++)
    {
        for(int page=0; page < pDocuments[doc].Pages.Count; page++)
        {
            pDocuments[doc].Pages[page].Print();
        }
    }
}

While that isn't very complex it does create 3 levels of nesting, and the function is performing three different tasks.

Split the work and loops makes it easier to maintain.

function void PrintDocuments(List<Document> pDocuments)
{
    for(int doc=0; doc < pDocuments.Count; doc++)
    {
        PrintPages(pDocuments[doc].Pages);
    }
}

private function void PrintPages(Document pDocument)
{
    for(int page=0; page < pDocument.Pages.Count; page++)
    {
        PrintPage(Pages[page]);
    }
}

private function void PrintPage(Page pPage)
{
    pPage.Print();
}

One could argue that the above is extra work, but the time spend to split the tasks and create functions of single purpose will reduce effort later when maintaining the code. The reduced indention makes it easier to read. The work to be completed by a loop is never performed inside a loop, but is handled by a dedicated function for that work PrintPage.

Conclusion

Single purpose and inverted logic are the keys to reducing indentations.

Answer 2

As you have already noticed, bunching up control logic to reduce indentation is totally counter-productive. The problem is not actually with levels of indentation, or number of lines. Those things are just indicators of the actual problem: doing too much in one piece of code.

The solution is to refactor nested, complicated loops into separate methods so that both the calling and the called method can be understood as doing one sensible thing. If your loops need too many local variables to be easily separable, a method object can be useful which encapsulates those variables with a large local scope into the class scope of a new special-purpose mini-class.

The same applies to complicated controller logic: if the condition of continuing or stopping a loop contains many complicated expressions, then refactor it into a boolean method with a sensible name. The object is to make the top-level logic to be obviously correct provided that the ancillary functions are correct, and the helper functions so small that they can be verified easily by themselves.

Answer 3

The idea behind these guidelines is that, when you find yourself in a situation such as yours, that there is most likely (not always, mind you, but still more often than you think) something wrong with your algorithm, and you should step back and rethink it.

I actually don’t think that refactoring will help you much, if it’s indeed an O(n²) or O(n³) algorithm – it might even worsen legibility (for people with wide enough terminals…) and reduce speed. (Of course, if you can improve the situation by refactoring without losing anything, by all means do so!) Really, step back, maybe let a coworker or someone else look at your code and algorithm and give advice… and if nothing else helps, ignore the guideline for that one function – with a detailed comment on top, of course.

Answer 4

• Put the innermost loops into functions. This also aids readability.
• Rearrange your code to short circuit instead of nest. For example, instead of if (condition) {big long nested code}, use if (!condition) return;
• Preprocess data into an intermediate form that doesn't require as much nesting. For example, if you copy a linked list into an array at the start, you might be able to avoid a nested loop later that traverses the linked list.
• Use recursion instead of nested loops. Recursion often greatly simplifies deeply nested code.
• Use exceptions to exit nesting during error conditions instead of checking at every level.
• Try to find algorithms that are more efficient than O(n³).

Answer 5

Are there any good ways to avoid that? One problem is, if you try to avoid complex if/else statement nesting I tend to do this in one row which can look very terrible and be unreadable and not very easy to maintain.

Use local functions to embody the bodies of these conditionals. By doing this you cut a line between the workflow (supervisor) and the tranformations (performers), which improves clarity.

At a first glance, adding local functions makes reading harder because it breaks the reading flow of the program, but actually, it improves clarity because it separates the workflow from the transformations.