Taking something that can't be done, and then doing it.

by Jiří {x2} Činčura

Testing NDepend on FirebirdClient

Published 6 Jun 2016 in .NET, Firebird, and Visual Studio

Couple of weeks ago Patrick Smacchia reached to me and offered me a license for NDepend. At that time I was actually in some code cleanup in Fast 5 software and though it might be handy to try it. As usual a lot of other things took priority and only now I’m able to start playing with it. Because I needed some codebase that’s not huge and also not small, I took FirebirdClient (both ADO.NET provider as well as EF6 provider). It’s open source so you can try it yourself and it contains some ~10 years old code so there will be something to look at, for sure.

Because it’s NDepend, I have to look at dependencies graph, right? Here it is (you might open the raw image and scroll a lot).


Yes, the layering is not perfect. But it’s not crappy either, is it? Occasional runs with chainsaw causing breaking changes are paying back. At least here. 8-)

Also some metrics were collected. The version has:

  • 13 586 LOC
  • 243 types
  • 2642 methods
  • 485 files

All this in 213 source files. And there’s much more in the generated report.

Then I found a feature to compare two versions of sources and draw some statistics from that. Very interesting are rules around API Breaking Changes. Although I’m trying to be pretty organized with FirebirdClient, especially when there’s a breaking change it is discussed upfront, something might slip in. For big projects, this I see as a useful safety net.

So. I took the version and compared it with (because I had that in hands already). Basically looking to see what changed between two major versions. Heck I don’t even remember what was the major theme in 4.x anymore. :) Here’s the report (this time only ADO.NET provider itself).

Interesting that even the functionality was added in general, all the cleanup around resulted in loss of LOC 4,62%, types 2,25%, methods 11,04% and files 2,82%. Only namespaces (one to be precise (the support for Firebird 3’s protocol)) were added 7,14%.

Some other numbers I though might be interesting too.

Code size:

Code size

Code numbers - maximums and averages:

Code numbers - maximums and averages

Third-party assemblies usages:

Third-party assemblies usages

I know looking at the report that there are some critical rules violated. Some might be right. Some (maybe even bigger part) not, in my opinion. Not that these rules are wrong. For generic code they make sense. Here’s it’s often enforced by environment. But if you feel like tackling some of them, feel free to issue a PR.