As Paul Dilascia discusses in his article in MSDN Magazine (most of which I am gonna mooch-off here), What is good code? Does good code mean that the program works as it is meant to without bugs? Well if that is your only criteria, then I don’t think so, that is something that is expected. One also needs to look at it internally - as they say beauty is beneath the skin (or something like that anyways). As Paul asks what internal qualities produce perfection (for the application/code)? It does not matter what language or platform you program in - one needs to remember the things that were taught in school when you took your first programming class - simplicity, readability, modularity, layering, design, efficiency elegance and clarity.

  • Simplicity - It does not mean NOT writing 10 lines of code for something that can be done in 5 - but rather to make the extra effort to be concise but not to the point of obfuscation. It also means that your functions should not be spanning pages. Simplicity makes the code easier to manage and debug making it more reliable and hence bug free.
  • Readability - This means that the others can read your code. It means you take the effort to write comments and explanations (for very complex things) in the code. It also means to follow your coding guidelines and choose variable and function names carefully
  • Modularity - I like how Paul put this. This means your application is built like the universe. The world is made of molecules, which are made of atoms, electrons, nucleus, quarks and strings! Similarly, good programs build large systems from smaller ones which in turn are build on smaller building blocks. Just as atoms combine in novel ways, software components should be reusable.
  • Layering - This means that internally your application resembles a layer cake (slurp, smack, drool). The app sits on the framework which sits on the OS and within the application you follow a similar paradigm. The higher layers should call the lower ones which in turn raise events back up. Lower layers should never know that the higher ones are upto.
  • Design - This means read Dilbert! Invest the time to plan and design your application before you build it - much much cheaper in the long run.
  • Efficiency - Means the application should be acceptably fast and economical i.e. it does not hog any resources. It loads and departs without a fuss. At a high level you need to be aware of your performance requirements.
  • Elegance - This is like beauty - hard to describe but easy to recognise. Elegance combines simplicity, efficiency, brilliance and above all pride.
  • Clarity - This is the “granddaddy” of good programming. The fundamental challenge of programming is managing complexity! All the other points mentioned above are ways to achieve clarity - clarity of code, clarity of design, clarity of purpose. You must understand and really understand what you are doing at every level. Bad programs less often a failure of coding skills than of having a clear goal which is why design is the key. If you cannot write it down, you cannot explain to others, you don’t really know whats happening!

I am a big believer of the principle of KISS (Keep It Simple and Stupid)! All the above points to that. In the real world there are very rate instances where someone has not tried to make this more complex than it needs to be (with yours truly being guilty of the same). But everyone learns (and so did I). The key is to remember KISS and that your design needs to be good. If the architect on the project is not making that clear (or doing it correctly), then he/she/them need to be told!

What do you think makes good code?