I was just reading blogs and stumbled across this gem:
http://codebetter.com/blogs/patricksmacchia/archive/2008/08/26/nhibernate-2-0-changes-overview.aspx
Patrick ran NDepends (an awesome static analysis tool) on the 2.0 release of NHibernate.
Patrick went on to suggest that the NHibernate code base was spaghetti because its internal namespaces are cross dependant. Having looked at the NHibernate code base, I disagree. In fact as a base for learning more about programming by reading others source code, I have found NHibernate to be an excellent source of learning.
I tried to post this as a comment, but I couldn’t (maybe my Opera browser, or lack of JS?).
“IMHO, the NHibernate team should fix this problem asap”
I can fix it easily, just flatten out the namespaces. Put EVERYTHING into the NHibernate namespace and this wouldn’t be a problem.
Is this the right thing to do? NO! But it does fix your metric. So I assert that your metric is wrong.
Who care if namespaces are cross dependent? I don’t. Namespaces are for logical groupings of behaviors. If your behaviors are cross dependent, so will your namespaces.
This metric may be useful in a typical 3 tiered layered business application. NHibernate is not that. It is one ORM library. ONE. I do not find your metric useful.
Given any metric that you are using (P/E ratio for stocks anyone?) please be aware of what that metric actually means and consider its value in that specific case. Yes, you must reconsider each metric on a case by case basis.
Jay, as you can’t post on my blog, I answer you here :o)
>Who care if namespaces are cross dependent?
Me :o) It is all about componentization. If you consider that the NHibernate code is a single component, then use namespace for logical grouping and make them interdependent.
However NHibernate weights 36 K Lines of Code, this is really huge for a single component. When one touch one methods, it means that potentially 36 K Lines of Code behavior can be modified since everything is inter-dependant.
If namespaces were consider as component, and for this the necessary condition is that they are layered, meaning no dependency cycles. Then each namespace could be developed and tested independently of others.
I detailed all these here:
http://www.theserverside.net/tt/articles/showarticle.tss?id=ControllingDependencies