My definition of good code

Author: Gaurav Mali | Date: 06 January 2013 | Subscribe Subscribe to Gaurav Mali

My friend and I got in this discussion last week and ever since then, I have been wanting to write about this topic. Although there are tons of books written on software engineering principles, software development methodologies, and programming philosophies, I haven't found a set of rules written in stone anywhere to qualify something as "good code". It's an ongoing process of testing, working towards simplicity, improving upon the design and architecture, and so on. Yet, so many times when we look at a file, we cringe and sign it off as something only a monkey would have banged out on a keyboard.

Personally, I don't get in a bad mood by seeing someone ignore well known practices in their program. My only test for the approval of code is whether it is "good enough".

What does "good enough" define? For me, good enough is something that works, and can be improved upon. Forget design patterns, simplicity, and elegance. If it works, it is acceptable. And if a programmer that has never coded in this particular language can read and understand what is going on, it is "good enough". Because if someone else can understand it, they can improve it. This is the least you could do.

In it's simplicity, this is how I define good code. Great code however, is a different chapter of it's own. As I continue to do internships at various different companies, and get to learn more about engineering decisions, I will update my views on that matter. For now, this is my definition of good code. What is yours?

Another interesting thought: Best email newsletter ever