If you are a developer, I think you heard the "clean code" phrase many times before - if not, you are in danger, exactly like what I was in.

To simply define clean code, the code that is being considered that the developer/others in the future will use/maintain it. In other words, if the code is written understandably ( for people who are not involved too much in the logic of the code ), changeable ( with the lowest cost, in terms of time, lines of code to be changed/added and minimum complexity to be added to the code ) and extendable, the code is clean enough.

there are tons of books and articles, advice, and rules to make the code clean, that I do not want to mention - I will put some books for reference at the end of this article, but you can easily find a lot of materials by a short search on google. Here I just want to talk about how I experienced the cost of dirty code I developed myself or others. In fact, in this article, you will find a list of problems I had because I and my colleagues didn't write clean code.

Coding does not mean cryptography

I do not know if you can believe it or not, but in my first job experience, I should work with an Assembly language code base, developed for a device with almost 2KB of Flash and 256 Bytes of RAM ( something common in Embedded systems 30 years ago ). To describe the code, it was mysterious! it was being written in a way that nobody else can understand, can you believe it? the maintainer was being paid just to maintain the code for ten years and he didn't write any documentation about it and nobody else was able to maintain it. After a lot of time, I finally learned how to do some minor changes to it, but we reject most of the new requests from customers to add or change any feature, because the original developer was not available, and the product almost get dead because the code was not clean.

The first thing I learned in my first job was: Do not to write code in a way that can not be understood, instead, write code that is easily understandable for everybody who knows the language and software development.

Never rush in developing software

The next experience I want to talk about was when I was a fresh team leader and we were asked for developing software for a project with a bounded time and specific features to be produced. The manager asked me for time estimation and I consulted with the team. We finally replied to the manager that - for example - 6 months is required to develop the software for that project. Sometimes after starting the project, we found out that 6 months was very tight timing and there was no option for us to extend that, so I asked the team to develop the code as fast as possible and we didn't spend enough time for review, test, and documenting the code. after about 6 months, we had the code that was working (just working) and we delivered it to the customer and waited for their feedback. When we received our first suggestions for change, we found out that we need additional 6 months to deliver that features. I didn't insist on developers developing clean code and instead asked them for some code that works. I think it is clear what happened next, we failed that project and I learned quality is much more important than quality (speed). Maybe you say It is obvious, but not for us at that time.

Consider it your last chance

I remember two situations in two completely different contexts, where I was working on a project, but my assumption was that I will just write a proof of concept code and the code will be written another time with better design. Do not want to make the story long, I wrote dirty code, it shaped a big mess, but it was still working, and we found that rewriting the code takes a lot of time and we didn't have the chance to rewrite it, and ... yes, another failed project !!!

the advice I can conclude from this situation is that Never write dirty code, even for temporary situations, because it may last for a long time and you need to be responsible for that dirty code. I know that this is not really easy to accept and do, but I think after some time you will used to that, and then it will be a habit to write clean code.

Make it leave forever

Among a lot of failures, let me do some show off with exceptional code I wrote that is still working :-). I remembered I was trying to do some integration tests for a software product and I needed some tools to do a very common procedure that has never been automated before. Because I am lazy, I wrote a code to automate that process, - and I knew that somebody else will access my code and I will be judged by that code - So I tried to do that really cleanly and made it something to be used for a long time, and it is still, after more than 6 years being used. Yes, I wrote a clean code intentionally and it will work forever.

It's a rule that if you write a code clean, it will leave forever (at least for a long time) and I suggest considering it when coding.

Some references to know more about clean code

The first reference I want to introduce is the famous book Clean Code by Robert Martin. This book, followed by another book Clean Architecture from the same Author, is a really easy-to-understand book I want to suggest. Also suggesting the Author follow and search for other books he contributed to.

Another book I read recently and I found really interesting is Refactoring by Martin Fowler. He is also a very iconic writer and I also suggest he be followed and just check the books he contributed to too.

there are a lot of videos, courses, and articles you can find that give you a lot of information about how to write clean code, and finally, you need to practice writing clean code and ask others to give you feedback on it. For sure after some time you will learn how to write clean code and you will learn how to make it a habit.

Let's decide to be clean code writers this year ...

Enjoy Coding :-)