Why You Shouldn't Nest Your Code

I have to admit, I'm a never nester.

I know.

Shocking.

But there are more of us than you think.

Dozens. Even Linus Torvalds is one.

I mean, I haven't asked him, but I'll show you what I mean in a little bit.

You might be wondering, well, what is a never nester.

A never nester never nests their code.

Okay. Not never.

But we do have a disgust-o-meter which grows

uncontrollably as the number of tabs go up.

Nesting code is when you add more inner blocks to a function.

We’ll consider each open brace to be adding one more depth to the function.

So this function is one deep because there's no inner blocks.

And if we add an if statement, we've made it two deep.

If we add a loop, we've now made this function three deep.

And this, my fellow

programmers, is the maximum a never nester can handle.

A never nester doesn't dare to go four deep.

Now the perverse among you might wonder what four deep even looks like.

And while it brings me great pain to do,

I understand that I must show you for science.

Here is four deep.

We've now taken a reasonably readable function and dramatically increased

the amount of conditions your brain must simultaneously hold.

But what can we do about it?

Well, there's two methods you can use to denest: Extraction.

This is where you pull out part of the function into its own function.

And inversion, which is simply flipping conditions

and switching to an early return.

Let's look at extraction first.

We can extract the inner part of the loop into its own function.

Now we can apply inversion.

When you put the happy path of code

within deeper and deeper blocks, it creates a lot of nesting.

Instead, we'll invert that condition and put the unhappy first.

First, we'll flip our if else, by inverting the condition.

Now, since we can return here, we know that the else block isn't

actually needed so we can flatten our else into the main level.

Now, if we hit our unhappy case

condition here, we simply get out of the way.

And then the main part of the code can do its job.

When you have a lot of conditions to check like this,

we can apply inversion over and over again

and we end up with a sort of validation gatekeeping section of the code

which sort of declares the requirements of the function.

And then we have the

crux of the real functionality here.

And you'll notice that the happy path moves

down the function and all of the error paths.

They're indented.

When reading this code, I find I can mentally discard

the condition and focus on the core code versus when it's nested.

I find myself having to hold these ideas in my head.

I'm curious if you’ve experienced the same thing?

Let's look at a larger example.

All right.

Look at this beauty.

Before we go refactoring it,

let me walk you through what's happening.

The goal of this code is to download a bunch of files from the web.

It talks with this download class that we can't alter.

It's an async download.

So when we start the download, you have to call process over and over again.

And each

time it gives you one of these results.

If it returns InProgress, we'll need to keep calling process() more.

On top of that, we want to download multiple files at once in the background.

So we've created a thread that manages all of them.

The way new downloads enter the system is through this append download method,

which puts the requested URLs onto a queue.

The thread then wakes up and grabs the URLs from the queue

and then adds them to this list of current downloads.

Each download is given a state

which is either pending InProgress or Complete.

So in each cycle of the main loop, the thread walks

through each download and checks what it needs to do with it.

If it's pending we start a new download.

If it's complete,

we simply remove it from the list.

If it's InProgress, we call that process method we mentioned earlier

and figure out what's happening with the download.

If it's completed successfully, we mark it as complete

so it can get removed from the list and InProgress means

we do nothing because it's still ongoing.

But things get interesting if we hit an error,

if the connection was okay, but we got an unhappy HTTP response.

We determine whether the air is retriable

If it is, we retry up to three times,

setting the download back to Pending.

Once it's failed plenty, we ejected from our download list

and push it to a failure queue for someone else to deal with.

For connection error, we retry three times.

Then we set the special connection disabled flag and this causes us

to basically give up on every download and clear the list.

Okay, so there's a lot going on here and it's all heavily

nested in this function, which makes it hard to follow.

So let's apply extraction and inversion to flatten

the first two big candidates.

Here are the two big branches of download processing:

Pending and InProgress.

So let's extract these out.

We'll move the pending part to processPending()

and InProgress

to processInProgress().

That's a bit better.

But this in-progress function is still too deep for my liking.

The worst offender is this HTP error section.

So let's move that out as well.

Now we'll keep extracting further in our run function.

We have four major sections of our code.

Where we process incoming requests from the queue;

Where we deal with our current downloads;

where we clear out the InProgress downloads,

and where we wait for the signal that there's new downloads to look at.

So let's do it.

So now

our main function clearly outlines the steps that are happening.

You can see the high level logic I described before.

And if you were to dig into any of these functions,

there are also concise.

At the beginning of this video, I mentioned that Linus

Torvalds is a suspected never nester.

And I say this because in the Linux kernel style guidelines they state

if you need more than three levels of indentation, you're screwed anyway

and should fix your program.

The kernel dudes are always so dramatic.

They visually enforce this

by making the tab size eight characters wide.

This is what eight characters look like with heavy nesting.

Yeah.

I'll admit I'm not that committed to the cause, but I am into limiting indentation.

I believe that constraining

how much you nest forces you to write better code.

If you notice, instead of one large function that handles many things.

We now have small, concise functions that have one responsibility.

What do you think?