Give Clean Code the Importance it Deserves
What is clean code? Why is it important? How important is a programmer’s native language in all this? How can stakeholders and programmers approach the matter?
What is good code?
It seems that when we begin our careers, good code is more related to things like performance, reliability, flexibility, etc, but not so much with code’s readability. A couple of years down the road we come to appreciate the importance of writing code that is crystal clear. To me, good code has to be readable code. Don’t take it as a necessary and sufficient condition, readable code can surely be bad, but if the code is unreadable then it can’t be good.
So, what is readable code anyway? Quick answer: code that humans can easily understand. But how do we make it readable? How can we tell when we are writing readable code or not? Truth is, there is no quick answer. In the rest of this article I am going to give you some ideas on how to go about writing readable code and why I think it is so important for programmers and business stakeholders. Let’s begin with the “why”. Why is clean code so important?…
Whose product is it anyway?
In the business of custom software development, each product we create is our client’s product, no doubt about that. They can do whatever they want with it, use it internally or sell it to somebody else, but most importantly they can extend or modify it themselves. To do that, what they need is to have the source code. So when we build software for our clients, we deliver not only the executables but the source code to them.
What if the code we gave them was incomprehensible by any other developer? Will they be able to extend or modify it later? Let’s use an extreme example:
Think about javascript minification. Minification is a process in which a file is transformed into a very compact version of itself, by removing spaces and by replacing variable and function names by shorter character sets like this:
|
1 |
var age = getAge(user); |
will get transformed into:
|
1 |
var a = b(c); |
When we release a javascript file into production we want to have it minified, not only because it saves bandwidth (javascript files are shortened when minified) but because it also makes it really hard for others to reuse the logic embedded in the code. The structure of the code is the same as the original, but since we made variable names and method names meaningless, the logic is now almost impossible to understand. So, we are protecting (very basic) the intellectual property of that piece of code by making it unreadable.
The point is, giving our clients unreadable source code for their products can be compared to giving them the minified versions of our files. They wouldn’t be the actual owners of the product, would they? They wouldn’t be able to understand the logic in order to extend or modify it. They would always need us to do any modification or extension to the product.
Even more so, what if the client comes back to us 1 year later to have the product modified and the team that worked on it is no longer available? Will other team be able to work on the product?
Who wrote this?!?
90% of the times a programmer is confronted for the first time with source code written by others, they won’t approve of it. You will find them saying things like: “What is this thing doing here?!?” “What is this for?!?” “Where is this coming from?!?” “Who wrote this?!? I will find you!”