Programming Pet Peeves: Crazy-Ass Indention
Look at that image. Don’t you just want to strangle the person who wrote that code? One of my frustrations when looking at other people’s code is seeing code blocks with really deep indentions. Let me tell you the reason why I find this annoying.
Deep (and complicated) Logic
This would probably be the most important point I’ll be making. Usually, the reason why you’ll see indention inside a method is because of an if statement. Having an if statement in your code usually means a fork in your logic.
While it isn’t really a sin to have forks in your logic within a method, there will come a point where you have too many forks than what the brain can keep track of. This is a sure sign that the logic for your method is complicated and, therefore, can be refactored even further.
Visualizing Logic With Flow Charts
One way to visualize the flow of the logic within a method is to use flow charts. Let’s take the above example and rewrite it in Java, because I’m a Java man.
In flow chart form, this is what this method would look like:
In my opinion, this kind of logic flow looks messy. Or if not messy, I can at least say that this can be tidied up a bit. Just like what I did here:
This functionally does the same thing, but is more pleasing to the eye. Understanding it also requires less cognitive load as visualizing it as a flow chart is a lot simpler:
So instead of having n levels of logic (where a “level” is represented by indented code and n is directly proportional to the number of conditions you check), you just have two. Clean AF.
Avoiding Deep Indention
Here are a few tips that I follow that can help you avoid getting deep indention in your code.
Keep your eyes on the prize (the positive case)
I’d like to think of methods as a set of commands that work towards a singular goal. You start a method with a set of things that you’ll be working on, manipulate them until you get the desired output you want, or stop if you find anything funny. A benefit of doing this is that you know that your positive case lies somewhere at the end of your method. Everything else in the middle are negative cases you encountered. Looking back at the examples above, here’s what the first one looks like:
As opposed to my version that looks like this:
Doing the latter helps you separate your cases properly, a plus for maintainability. Let’s say you’ve suddenly decided to lift a constraint, say you don’t have a character limit for the username anymore. I bet it’ll be a lot easier to locate and delete the two lines you need to if you did the latter rather than the former.
Handle edge cases early on
Let’s say you have a method that gets an object from a collection, something pretty common in Android Adapters.
Two edge case exceptions you could potentially come across are
I could see some developers potentially write something like this to solve that problem:
Cringe. Here’s a flatter, cleaner way of doing it:
All edge cases handled in one if statement. Negative cases separated from the positive case. Very nice.