I have to admit that the idea of Clean Code is something new for me, and it felt like something that I never knew before! That fact changed when I got to know about Scrum; the Agile development framework. After I attended the Test-Driven Development (TDD) Workshop from Odd-E, someone recommended a book called ‘Clean Code’ that changed my perspective on how to write codes!
As Martin Fowler once said: “Any fool can write code that machine can understand.GOOD programmers write code that humans can understand.”
Ever since then, I always try to pay more attention when writing codes. Here are a few points that I keep in mind:
- DON’T write any production codes without having any unit testing
- DON’T add anymore duplicate codes
- DO improve the code base so it is better than before
But, are these helping me to write a clean code? Not exactly… but it certainly made me care more about the code that I write, at least more than before!
What is Clean Code?
The definition of clean code varies for different people, although I think everybody agrees that clean code is not “dirty code”. Erm… but what do you mean by dirty code? Dirty code has one characteristic, something that we recognize as code smell. Like many other dirty things, we try to avoid or refuse to get involved with it, same thing applies to dirty code. So, my definition of clean code is a code base that I am comfortable to work with- it is the code that is easy to change and maintain. One should only take a few scrolls to be able to see how much the author cares about the code.
Why should I care about Clean Code?
Have you ever encountered a situation where you need to apply your changes, clicking Ctrl+C and Ctrl+V through all code base, scrolling through a few hundred lines of a function trying to understand what it does, or not knowing which function to use? That happened to me not only once, and I realised that these are the signs of code smell!
When I reflect back to my code base and contemplated if there was no duplicated code, I would only need to make a change in one place (sounds nice, right?). Then having a clean code base brings many benefits, especially for the codes that we need to maintain regularly.
Duplication is the root of all evil! Most of the code smells are always related to duplication. Duplication comes in different forms; they could be something that looks similar but fundamentally different. For example, two functions might be doing exactly the same thing with different names and parameters. When I remove the duplicated codes, it helps me to discover other signs of code smell. And it is actually fun to remove them and see how the codes can be transformed to be cleaner!
A good variable or function naming can help in understanding the code without having to read the implementation. For example, if I have a function named XX() – simply by looking at the name, can you understand what it does? Probably not, instead, you will need to take extra steps to find out the function name and where it is being implemented. But, if the function name is computerSquareOfX() – now this is more straightforward, isn’t it?
Function This is a sign that the function is trying to do too many things and it is probably too complicated to change. We should try keeping the function short, but how short is short? Well, according to my experience, any function that has more than 10-15 lines is considered too long. But again, this is my two cents worth and not a definite rule for you to adhere.
How do I clean up code?
First , you need to STOP writing dirty codes. After that, refactoring – when you are refactoring the codes, it can be as if you are going into a war! You will need a good armour to protect yourself from enemies (bugs) and a sword to eliminate those bugs. In other words; you need to have good unit tests wrapping around the area you want to change before you do refactoring, and some good refactoring tools that can help you do the job. For example in our case are NUnit, Resharper, Code Coverage tools, Continuous Integration (CI) server, etc. STOP writing dirty codes Refactor the codes But to have a good test in place, you need to refactor your code first. Oh wait a minute, does it sound like the chicken and egg problem here? Probably not since there are a few safe techniques that you can employ to do refactoring without conducting a test. For example: “lean in compiler”, “extract interface”, “scratch refactoring”, “extract and override”, “renaming”, etc. These are just a few to mention, and many more are described in the book ‘Working Effectively with Legacy Code’. Psst, this book is available in our library!
Where can I learn more?
Like many other things, we learn best when we practise it and there are so many trainings and tutorials online waiting for you to tackle them. If you really cannot find anything, just practise with your code base and how you can make a cleaner code. Reading books help as they provide techniques to deal with certain problems, or show you other perspectives to a problem. This won’t happen if you write clean code! It is easy to write code, but writing a cleaner code requires more effort and would not happen overnight. It takes time to learn and experiment. Find your own motivation, I can explain to you over and over what is a clean code, but it probably would get you nowhere if you only read about it.