This article was written as a submission of CS UI’s software development course’s article task.
Defining what ‘clean code’ is can be subjective. Of course, there’s an absolutely fantastic book written by none other than Robert C. Martin that goes into thorough detail on what the term means, in this article, we’re not gonna delve nearly that deep; instead, we’re gonna talk about the part of ‘clean code’ that pretty much everybody agrees on.
Among the many definitions of clean code that you can find if you look hard enough, I found that most of them can be distilled into one sentence that everybody agrees on, which is:
“Clean code is code that is easy to understand and easy to change.”
While some developers would argue that that statement doesn’t really say anything at all, I find that sentence as an excellent “in a nutshell’ definition of this idea.
Easy To Understand
Most programmers know what this means by now, as it is pretty much drilled into our heads when we first started programming. “Name variables in a way that succinctly describes the data that it holds”. “Write comments only when it is truly necessary”. However, the importance of these simple practices cannot be understated. Take a look at the following “dirty” code.
I wrote that code. I know exactly what it does. But how much time do you think my future self is going to need to comprehend what the hell is going on here? let alone a completely unrelated person who just so happens to unfortunately inherit this code in the future? Reading all the comments that describe each variable and remembering what each variable does is already a challenge in and of itself, you can imagine how hard it would be to understand the logic behind the thing.
Now compare that abomination to this.
Much easier to understand, no? Sure, you still wouldn’t understand the code instantly (it’s a pretty complicated part of the application that requires knowledge of models), but you can immediately notice the stark difference between this code and the last. For one, variable names actually describe what the variable is (safe for “waobj”, I guess). You can immediately tell that “previous_url” is supposed to contain a url that links to an endpoint, most likely something prior to the execution of the method. You can immediately tell that the for loop loops through “subactivities” and does something with each “subactivity” that it contains.
Although the above example wasn’t perfect, it aptly shows just how much of a difference naming your variables can be. In the long run, it will save countless of man hours, and by extension, money.
Easy To Change
I’ve always struggled to understand this part of the clean code dogma. What does it mean for a code to be “easy to change”? No matter how dirty or bad your code is, doesn’t it take the same amount of effort to change? after all, regardless of code quality, at the end of the day, you type to change it.
You might cringe at my foolishness, I know realize that what they mean when they say “easy to change”. It means that whenever you need to change something, you don’t need to spend an eternity editing dozens of lines of code and wondering if it’ll still work. To that end, I’ve found that the DRY (don’t repeat yourself) practice is best. Here’s another example of “dirty” code.
This part of our tests suite tests scenarios where users are already authenticated (usually each ‘authenticated’ test is placed above their “unauthenticated” counterparts, I rearranged it this way for brevity’s sake). Notice how each and every one of those tests start with posting to ‘/accounts/login’ to authenticate, with the exact same credentials.
Now what if those credentials change? In this case, I have to edit 4 tests, which isn’t that big of a deal. But what if I had 100 authenticated tests? What if the function in question wasn’t a simple “authenticate” method, but a much more elaborate one that required 30 lines of code to post to another api? That would certainly be a bummer, wouldn’t it?
Now compare that code to this one.
Now, anytime I need to make changes to the “authentication” part of the tests, I only need to edit one function; the aptly named authenticate(). Even if I had 1 Million authenticated tests, I only need to spend a few seconds editing 2 lines of code if the credentials changed.
Of course, there are much better examples of code that could showcase how important it is to make your code as easy to modify/change as possible, but I think that my anecdote did a pretty good job.
Conclusion
Although making clean code requires more thought, time and effort, the difference implementing it makes is staggering. It is very important for us to make easy to understand code, because software engineers, more often than not, work together to solve problems. So naturally, creating more problems would be counter-productive in our endeavour.
Thank you for reading, and I hope you learned something!