On the NHibernate leaders request, I had an opportunity to review/audit the brand new NH v3.0.0 code base. My analysis is based on facts obtained through the new reporting capabilities of NDepend. The analysis is published here on the NH official blog and here is the NDepend report on NH.
What I tried was not to just show what is good or wrong
in my opinion, but also to explain why I think it is good or wrong.
For a brief summary, NH is ok on:
- The too many assemblies problem (my god, 95% of professional projects I can see have hundreds
of asm, without any valid reason except to dramatically slow down everything on the
developers workstation and build machines!!!)
- Not enough code coverage, NH has a healthy global 76% code coverage ratio. I mean, just NH handcrafted and generated code, not counting test code. Btw, around 18K LoC are generated on a total of 63K LoC.
- API breaking change, the team is pretty careful with the NH public surface and this attention is made obvious by comparing NH V3.0.0 with the previous NH v2.1.2 version.
- Dead code
I found room for improvement in:
- Code contract usage, NH doesn’t use any code contracts Fx (nor MS Code Contract API nor Debug.Assert(…)).
- Despite the global great 76% code coverage ratio, many methods or types are 90%+ covered by tests instead of 100%. The problem is that often, subtle bugs hide in the remaining few percents hard to test and not covered code.
- A better global code architecture (this is not feasible since NH public API cannot be refactored for obvious reasons)
- A respect for basic code metrics quality thresholds (too complex methods, god classes, fat code, methods with too many parameters etc…).