One of my favorite quote from Donald Knuth that emphasize the programming is an art and communication not only human and machine, and it’s also communication between human-to-human.

When you write the code, you instruct the computer what to do. At the same time, you are responsible for letting the programmer knows what you intend to let the computer execute.

Having this mindset will help you build your code to better in future. It’s a win-win-win situation. The machine wins, coders, and you win because you won’t suffer if anyone writing poor code for you.

Anyone who learns the programming syntax can write the code to tell the computer what to do. Writing code without consideration for the future maintenance is not a good idea. A good developer should always consider the readability and prepared for future maintenance of the software they write unless It’s a temporary code which may be thrown away soon.

Writing poor code may save your times for short-term, but it and it may cause unwanted bugs when debugging it in future. You’ll end up wasting more time on debugging and figuring out the issues. The best practices for a programmer always make sure you refactored the code each time you wrote the code in case of end up you had to re-write the whole code.

Reading code is just like reading an article written by somebody else. An excellent article is commonly having a clear title, proper use of punctuation, correct use of grammar and without any spelling error. It’s usually well structured without much sloppy punctuation.

As a developer, we are responsible for writing quality software that serves everyone better. We should not always look for the short-term goal, considered of the future maintenance that the code you are composed. Reading your code repeatedly and refactored it where it needs. You can ask your senior co-worker to review your code as well. In others word, we called it to peer code review. It’s one of the conventional methods we used to improve our code quality today.

A lousy code may affect you and your team when they are trying to understand what’s you are intent to let the computer execute it. If the code is terrible unreadable, your organization may lose interested in continuing work with the code.

So, what’s code quality?

When I was researching for the definition of the code quality, I found that everyone is having a different but a similar definition of the code quality. Today, I’ll share one of the best definition of the code quality I found on the internet. (Thus I’m not going to define it my own )


Code quality is a loose approximation of how long-term useful and long-term maintainable the code is.

The code that is thrown away tomorrow is Low quality.

Code that is being carried over from product to product developed further, maybe even open sourced after establishing its value: High quality.

Since looking into the future can be somewhat tricky, we look at the present signs that may help to predict it.