Friday, November 16, 2007

Choosing What to Call

When we are face with several options to do achieve the same thing, how to choose it?. This is one possible scenario when it could happen (which I happen to encounter several time ) : You have OS API, library A, library B, language extension and finally Framework you use that provide the same thing. These thing could be something like : Tracing/Log, Multithreading, Date Time, String (represesenation/processing) and other area where people tend to reinvent the wheel.

But first, try to guess what language that you'll encunter this most often? hint : It started with the letter C and it's not C Language :).

C++ has stl, boost, loki, commoncpp (in gpl world), several flavor of unit test (which boost that I mention before has it too), libraries people write with variety of scale and coverage. It's fun, really. You can encounter this problem in other language too although less severe since later languages usually comes with more extensive standard library (and the word standard is quite important here).

Back to the topic, I find that if we just choose arbitrarily this could lead to a messy code (which lead to a massively messy head when it comes to maintenance). I use the below guideline in order although some cases would require for me to bend it sometimes, but it seems to work in general :

  1. If you work on platform/framework, choose whatever platform provide for you. Study it firs what helper function it provide for common operation. This will help you to do minmum "fitting" of data type, arguments and as an added bonus your code will look as a better "citizen" in this platform. Example : when you code in Directshow, study it's helper function and classes, it will smoothen your code (since you could avoid some nasty COM code although not entirely) and make it more maintainable.
  2. Choose well-known specific library compare the one provided in a library-package. You would have better resources in your hand in setup and using it and most importantly when you face trouble since many people using it. Example : CPPUnit would be a better option compare to Unit Test in boost library.
  3. Choose the one with higher level abstraction :Boost, then STL, then C++ then Syscall. The one with higher one abstraction will help you organize your code better, avoid you to reinvent the weel (read : save time) .
Those guideline server me well so far e.g: if something exist in Framework, I use it instead the on in the library. Sometimes it happens through process though. I would first use, by habit, certain function but later find out the framework has helper function for it (usually with relatively better abstraction) then change into it.

One caveat though : don't use what you don't understand. A certain construct is there for a reason and using it beyond what it's intended to do, although could work, could lower quality of code. So, choose only when you understand all the options well and not because you just learn it yesterday and/or it looks cool, otherwise, choosing what you understand most could be the best thing to do.

No comments: