Clean Code Session 1: Bad Code & Motivation

The year is 2016. Everyday, we – people – wake up, have breakfast, go to work, come back home, go to bed and sleep. This is a typical day put shortly. But there is something more than that – throughout such a normal, regular daily routine, almost all of our activities are supported by or even based on electronic devices of all possible types – smartphones, laptops, alarm clocks, cars (they are all electronic nowadays), ticketing machines at underground stations…the list can go on forever.

So, you might be wondering, why am I talking about our electronic surrounding environment when the title of the article states that we should be discussing something relevant to coding and development? The answer is simple – because all the electronic stuff around us runs code and, without code, it simply won’t work at all. Full stop.

As you know, I am a developer and, naturally, programming code flows around me throughout most parts of the day (and sometimes the night). However, there is something interesting which I can state is happening to me as well – with time passing and programming code being around you, you begin to look at it through a fully different point of view, from a perspective more of a piece of beauty rather than of a functional chain of characters. But, let’s not get too passionate for now, it’s pretty early.

Since, as I mentioned, programming code is really one of the running gears of our modern lives, it is also critical that we – developers – all look at it as a piece of art, not just a list of instructions, it is vital that we write CLEAN code. I realized this fact and became really keen on spreading the ideas of clean code, as well as the good practices I have accumulated over the years and exploit on a daily basis – no matter at work or when I develop something in my spare time. This is why I started this blog campaign bearing the name “Clean Code”, inside which I will share all my ideas and knowledge considering how to write better, cleaner and – most important of all – understandable and functionally more effective code. But first, it is important to have a detailed look over what is bad code, why every little detail matters and, once again, why writing clean code is a top priority for every developer.

First of all, I feel it’s necessary to express my motivation on writing clean code, so, I will do it using simple parallelism between programming code and something else. Imagine that you are in the situation of buying a sports car you have desired for a while. You find the advert for the perfect example of the model – nice red metallic paint, leather upholstery, top-of-the-range equipment, the most powerful engine for the model is present, etc. Naturally, you go on-site to check out the car and, after careful inspection, you discover the ugly truth which you were not able to spot on the pictures – there are little scratches on the paint here and there, parts of the interior are broken or worn-out, under the hood there are oil specks everywhere, although the owner claims mechanically the vehicle is fine – all nasty! What would you feel at that moment? You are right – disappointment. You will say “yes, the car is mechanically perfect, it looks good as well and is really fast and luxurious, but I will have to put money and effort to make it as shiny as I want to”. Now think twice – isn’t it pretty much the same with programming code? If you are a developer and you are given the task to extend the code of an application someone else has written, although it may be a well-known fact the app has cool features and works well, if you find variables named a1 and b2, silly comments or bad formatting, you will be really disappointed or at least irritated by these little but teasing things. Here comes my point again – if you don’t want to disappoint other developers or even yourself when you look at your code, you need to write it as cleanly as possible, always keeping in mind that it would be a pleasure if someone looking at your code said “wow, this is a real masterpiece”, wouldn’t it? Never forget that via practicing in the small you gain proficiency and experience in the big – every little detail matters and will pay back the effort you have put into making it perfect.

You see, in the current day of Scrum and Agile development, developers are forced to put the stress and focus on quickly releasing products on the market. In other words, developers struggle with the fact that they are obliged to work as if being on a production line, quickly develop certain features for a given product and push it to production state, without having time to carefully write the code that essentially builds the product and its features. The consequence is that, in the end, it turns out that roughly 80% of what programmers do is not development but maintenance. A product is forced to go on sale quickly while focus is put on deployment rather than on development. Then, some of the original code contributors quit the project and are replaced with other developers who “inherit” the code base created by the people who have already left. However, because the product was developed with market rather than quality goals in mind, it needs refactoring and thus the newly engaged developers spend more time fixing and maintaining the product than extending it. And at this point the product begins to degrade badly. If with time the features’ list continues to grow, maintenance necessity expands as well until the stage is reached when the product is neither maintainable nor extendable and…it is dead. I believe this explains quite well why writing clean code is so important – it prevents a given product from becoming non-maintainable and even reduces the need of maintenance whatsoever. But, if clean code is so important, how, in general, can we differentiate it from bad code? All in all, what is bad code in essence?

In his book, Clean Code: A Handbook of Agile Software Craftsmanship (which engaged me in the topic of clean code in an astonishing manner, made me a real defender of writing clean code and I really recommend that you have an extensive look over it), Robert C. Martin refers to a simple method of getting to know if you have written a piece of code that is bad. The idea is that,

during a code review, you should count how many times per minute the person reviewing your code has said WTF.


The measurement of code quality – WTFs/Minute. Photo credit:

In other words, the measurement for bad code is WTFs/minute – the bigger the number – the worse your code. Having written a snippet that makes the reviewer say WTF numerous times really means your code is, at least, unreadable or badly formatted. This, on the other hand, results in the mentioned tiring necessity of maintenance and enlarges this necessity. So, our simple aim of writing clean code can be measured by just paying attention if the person reviewing our work is happy or angry – this measurement is always correct.

Good, you already know what bad code is and why clean code is so important for both you and the product you work on. However, you may be asking yourself how, besides using actual tips and tricks, you can improve your abilities and begin writing clean code? Well, the answer is simple and straightforward – try to always look over the process of code writing as craftsmanship. When you feel that what you do is a craft, a piece of jewelry, approaches considering clean code writing begin to find their right place by themselves.

Knowledge plus practice equals craftsmanship.

Knowledge plus practice equals craftsmanship.

On top of that, looking at code writing from the perspective of a real craft can be achieved by two things – theoretical knowledge and real practice. The former is necessary so that you know how to do something, the letter – so that you now what you really do and both cannot go one without the other. You may, for example, read a hundred books which teach you how to juggle, but I bet that the first time you try, you will drop all these balls on the floor. You need the knowledge, but you need to make it “soak” through your fingers so that you can harness a given skill.

Furthermore, you should remember one thing – bad code exists because of you, not the people who requested that you implement a feature quickly and without care. As Robert C. Martin states, you are the author, not the person who gives the requirements – so you are responsible for what your code looks like and what form it takes. I know there are reasons you leave bad code out there in repositories – you may be in a rush, you may be fed up and want to finish that certain feature, you may need the feature implemented so that you can also work on the ten other features awaiting you in the backlog, but that does not justify the fact you leave bad code around. Remember the law of LeBlanc: “Later equals never” – it completely fits the described situations so far, doesn’t it?

LeBlanc's law: later equals never, or, as it is said in Bulgaria, never leave today's tasks for tomorrow

LeBlanc’s law: later equals never, or, as it is said in Bulgaria, never leave today’s tasks for tomorrow

To summarize our motivation for writing clean code, I can say that keeping your code arranged and constantly thinking when writing it is vital and is a matter of survival in the future, because let God be with you when you need to refactor that badly written feature of your own! Your code needs to always fulfill certain criteria, such as to contain no duplication, to be meaningful and self-documenting, to fully cover the requirements, to be concise and as simple and short as possible. But all of that will be clarified in the upcoming article.

So, for now, just re-think your style of coding. See you!


Leave a comment

Your email address will not be published. Required fields are marked *