Nesting bracket in code

Linus Torvalds said that code with more than three levels of nesting is considered suboptimal, stating, “if you need more than 3 levels of indentation, you’re screwed anyway, and should fix your program“. When code has too many nesting inside nesting, it becomes hard to read and understand. It’s like having lots of boxes inside each other – you lose track of what’s going on. To make it easier, it’s better to keep things simple, like organizing your code in a way that’s easy to follow. This not only helps developers understand the code better, but also makes it easier to manage and change in the future.

Imagine we’re looking at a simple computer program. It does some tasks and gives us a “yes” or “no” answer based on certain things. At first, it seems easy to understand.

But now, let’s add something more.

As we add this new thing, the program gets a bit harder to follow. It’s like the clear picture we had is getting fuzzy. This reminds us that it’s crucial to keep the program simple. When we make it too complicated, it’s tough to figure out what it’s doing. So, it’s a good idea to stick with simple code that’s easy to understand.

Adding more stuff makes the code more confusing. What used to be simple is now becoming harder to understand. The details are getting trickier.

As we keep making things more complicated, it gets tough to see what’s going on. The code, which was once easy to figure out, now needs careful attention.

So, it’s super important to keep the code simple and clear. If it gets too complicated, it becomes a mystery that’s tough for current and future programmers to solve. Finding the right balance between making it work and keeping it easy to read is key, so everyone (even the author) can understand it, now and later.

Ways of dealing with nesting

We have two main ways to handle complicated code: extraction and reverse extraction.

Code Extraction:

When things start getting too complicated, the first move is to take parts of the code and put them in separate functions/methods. This is called code extraction or refactoring. It makes the code easier to read, encourages reusing code, and makes it simpler to keep things in check. It makes code clear and easy to understand.

Reverse Extraction:

On the other hand, if the code has too many ifs, understanding every condition can be hard. Not to mention, we have too many lines of code. You can reverse conditions in a way, we first check if we can even proceed further. If not, just return with or without error code.

These strategies aren’t set in stone and can be used together as the code evolves. The key is finding a good balance between breaking things down into manageable parts and bringing them together for clarity. The goal is to keep the code both organized and understandable.

Extraction

Understanding that the most nested part of the code is the one checking if ‘index’ is equal to 2 is really important. In our example, this deep-down check happens inside an “if” statement.

As we look at the code, we see that this specific condition is just a filtering of data. It can be extracted to a separate method.

Reverse*

Filtering out conditions at the beginning of the code is a valuable practice. By validating critical conditions early on, you establish a simple path for processing, reducing the need for deeply nested structures and increasing code clarity. This approach is particularly beneficial when certain conditions can be quickly evaluated to determine whether further processing is necessary.

Implementing these validation parts not only simplifies the control flow but also makes the code more readable and maintainable. Developers can easily see the primary conditions for execution without diving into nested layers of code. Additionally, it can contribute to improved performance by avoiding unnecessary execution of code when certain conditions are not met.