Code like there is no if-statement

The if-statement is one of those fundamental tools that any software engineer uses to solve everyday problems. It is part of software engineering from day one, right after the student writes the first “hello world.” It is ubiquitous, and so is its destructive power.

Although engineers have been systematically blinded to this reality, let’s see how can we change our mindset to overcome the issue and win the battle against the infamous if-statement

There I was, in 2013, doing reverse engineering of a 20-year-old piece of software for which his original creator left no documentation. After several weeks, I understood how the algorithm worked — the beauty behind it — and, therefore, its edge cases. These edge cases were mapped by if-statements (or their evil incarnations), ending up with a forest of them across the code.

Just in case you are wondering, yes, its original creator used patterns to organize the code appropriately and make it readable, but the truth is, patterns just hide the if-statements for the sake of readability, but they do not get rid of them. So, in the end, they were all around — like a mosquito biting you all night long.

Was at that moment, I challenged myself with the following:

If there were a finite amount of if-statements that I could use per algorithm, how would I write the solution?

After some back and forth, I figure out that if-statements allow engineers to be lazy at coding, and furthermore, provide them with an easy way to avoid thinking about how to solve a problem eloquently — it creates a mindset of “Ah, there is an edge case, let’s write an if-statement”.

With that in mind, now we can talk about the mindset I promised to share at the beginning:

Think about a problem so that the edge cases become part of the norm and not an exception.

Let’s use this new mindset to solve an actual problem and see how it works, and in this case — just to reinforce my previous point on engineers getting systematically blinded on this issue — let’s use and algorithm engineers learn in the first year at college used on a particular data type called “Singly-linked list”:

Although it is a widely used piece of code and taught this way across universities worldwide, that code is as bad as it can get — and if you have paid attention so far, you may know why… yes, the if-statement at the end. We do not need to analyze the code in-depth, but in a nutshell, it handles a particular scenario when the entry needs to get deleted, but the way it is deleted depends on whether it is the first entry or in the middle (edge case)

If we use the new mindset — think about the problem in a way that the edge cases become part of the norm and not an exception — we can re-write this ancient piece of code in this new way:

look how the if-statement disappears, but more importantly, the edge case is now part of the norm and not the exception, and — as a significant side effect — the code gets more straightforward and eloquent.

Although this is an elementary example for us to grasp the main idea, the concept is far more complex; it is about seeing edge case patterns and knowing — instinctively — how to transform them into the norm. It is difficult initially, but it gets more manageable with practice.

Now go ahead and open that code you were working on yesterday and try to remove your first if-statement using this new mindset!