Monday, September 19, 2005

Writing good code...

The pragmatic programmers write great articles on writing good code. I especially liked this one Writing good OO code. How many time have you seen these seemingly obvious things violated? [Hint: 100s of times :)]

If you write code for a living, do take the time to read the article and save the poor souls who have to maintain your legacy :).

3 comments:

Anonymous said...

How many more times have you seen people go to ridiculous extents just to avoid these "seemingly obvious" violations? For example, overgeneralizing to keep it perfectly DRY, or, for that matter, writing chains of wrapper functions, one over another, just to be absolutely shy - i.e. to not violate the supposedly sacred Law of Demeter.

And, how many times have you seen these seemingly obvious things violated and yet end up successful as a product? I think, all these fatwas of OO design are overrated. Resorting to all sorts of fabrications just to be obedient to OO gurus when you have no idea what parts of the design will change considerably, and how much they will change, and in what ways they will change is only premature optimization of a different kind.

A few "wet" spots here and there, or talking to strangers once in a while will not immediately make your design a maintainability nightmare.

--MN

Kalyan said...

Well, you are right and your comments are, as usual, thought provoking ;). All the best designs in the world are useless if the product does not serve a useful purpose.

In the recent past I have been bitten by over-coupling between unrelated entitites (compile time coupling of random things rather than exposing an event that can be subscribed to, external lifecycle issues coupled into the logic of the normal object api, logic for copy of an object being present outside the class etc etc), so this article resonated with my pain maintaining code!

Actually the folks who write these articles are not rabid about these laws or anything. These are just guidelines to think about while developing code and tradeoff as appropriate. IMO, such thinking yields more testable and maintainable code.

I am not saying we have to have a IBlah, AbstractBlah, BlahImpl and BlahFactory for every silly thing :)), just that decoupling and tell apis are pretty useful when we write code that needs to be maintained for a few years.

Srinath said...

Read the article. Weren't you the one who complained some time back about these software engineering articles drawing parallels with random unrelated things. ( 'A code should be like a 4 year old kid hiding behind her mother's skirt' !!!??? )
Nevertheless, a nice article in terms of the content.