twitter

Thursday, May 12, 2005

Making Wrong Code Look Wrong

I've just read Joel On Software's new article entitled Making Wrong Code Look Wrong. I can't seem to follow his ranting. However, there's still some lesson learned from the rubbish, that is source code cleanliness is relative. This is the closest idea I could perceive that is consistent to the title. And the idea is indeed TRUE. Of course, if you're not a software developer by profession, there's no way you can relate to the idea.

One example that supports this perception is the use of Hungarian notation as a coding convention. For some developers, code written in Hungarian is neat, but for others it is not, specially for non-C/C++ developers. Personally, I prefer Hungarian when I program in C and C++, but not when I program in C#, I follow the Microsoft guidlines instead. This preference is largely influenced by what is popularly recommended by the developer community.

Basically, preferences to Hungarian notation, or any other coding conventions, seem to be influenced by the conditioning caused by the developer community per se, expressed through books, articles, or sample code found over the web. Which brings me back to my earlier point that code cleanliness is relative because each developer has its own criteria of cleanliness influenced by how he is conditioned to, whether he's conditioned to use Hungarian or Camel notation or etc.

Well, I have no idea where I'm getting at with this blog. I better close this with what I've learned from Joel on Software's new article which are :
  • Code cleanliness is relative. But algorithm is never relative. There's always a BEST algorithm for any given problem.
  • Resource Acquistion Is Initialization (RAII). Well, the article doesn't directly point to RAII, but it came via Raymond Chen's blog which points to this topic. RAII is not something new, it is just a programming idiom which aims to self-contain the obtaining and releasing of resources. One example for this is STL's auto_ptr. For more details of RAII, read this blog from Jon Hanna.

0 comments: