SLAP that ugly code!
The Single Level of Abstraction Principle is commonly known as the SLA principle, but if you are trying to make it sound cool for a medium story or a blog-post like I am, then you can call it SLAP. This principle was explained by many authors of software development literature but probably the one that most programmers remember hearing it from is Robert C. Martin (a.k.a Uncle Bob) in his popular book Clean Code(2009).
The idea behind this principle is that all the code inside a method should be at the same level of abstraction. This way it is easier to read and understand the code. If code is expressed with different levels of abstraction within the same method, this will could result in confusion, and difficulty understanding.
Mixing different levels of abstraction in one same method can make it harder to read and understand. We should always try to keep the code inside our method at the same level of abstraction.
Is also important to mention that respecting the SLAP principle does not necessarily mean that your code will be shorter, it just means that it will be easier to read.
This principle even if doesn’t seem like much, it’s extremely important because there’s a very tight relationship between readability and maintainability.
Code that is easy to read and reason about, is easy to maintain
Probably now I should show you some code example of this principle but I thought to first continue just for a few more lines with a bit more boring, but necessary theory. The reason is that, I feel that even if this principle is easy to understand and apply, yet some programmers don’t follow it. But why?
Well, I was meditating a bit about it and I came to the conclusion that the reason why some programmers don’t follow it, is because they feel lazy to refactor, and also once they implement a feature, the think they will not return to that part of the code anymore. But it is not until they return to look at code that they didn’t write or that they wrote long ago that they sense why SLAP is important.
The computer scientist Edsger Wybe Dijkstra in the 1970’s first time mentioned the concept of separation of concerns in a publication about scientific thought. Without going into too much detail, the idea of separating the different aspects of a problem allows the scientists to solve one problem at a time and eases the process of reasoning. So as you can see there’s a relation between Dijkstra’s separation of concerns and the modern SLAP principle.
The boring theory is over, now yes have a look a little bit of code. Please briefly look at this bit of code, but not for too long because is an abomination, your eyes may hurt.
In that code example above we can clearly see the SLAP principle violated. For example line 3 is delegating a behavior that is probably similar to the behavior on lines 2 and 4. Also, those variables are trying to express some more abstract concepts but they are mixed with the low-level implementation detail.
We will now show a little bit of code that aligns hides the detail pushing the complexity to a different level of abstraction and leaving in the method something that at least can be read.
Now it’s easier to understand what the method is doing because the code inside it, it’s at the same level of abstraction.
If you liked this story, please give us some 👏 and follow us
