29. December 2008 00:44
I got today back on an old controls assembly. I am using DevExpress controls for more than a year. But there are still some forms using my old control library. It would have been a mess cleaning up this old directory, until i realized that this could be done very easily using NDepend.
I loaded the assemblies and used the dependency matrix to find out where the controls are used.
Especially the “Remove Empty… Rows and columns” gave me a quick overview of controls which still where used on some forms and should have been replaced by other ones.
Furtermore i looked – just for fun – at the “abstractness versus instability” graph created by NDepend. I took a screenshot:
As you can see, it ain’t looking good. When i started developing this application, i never heard of abstractions and instability was my middlename. Well… None of my assemblies are in “zone of uselessness” (upper right corner), but i know the “zone of pain” very well.
The numbers aren’t lying:
Number of IL instructions: 1006520
Number of lines of code: 121799
Number of lines of comment: 22251
Percentage comment: 15
Number of assemblies: 11
Number of classes: 849
Number of types: 896
Number of abstract classes: 2
Number of interfaces: 10
Number of value types: 4
Number of exception classes: 0
Number of attribute classes: 0
Number of delegate classes: 0
Number of enumerations classes: 33
Number of generic type definitions: 36
Number of generic method definitions: 5
Percentage of public types: 86,27%
Percentage of public methods: 80,31%
Percentage of classes with at least one public field: 2,23%
I know i can do better :-)
21. June 2008 08:58
A few days ago I received my NDepend license.
What is NDepend
On their web site (http://www.ndepend.com), it states that :
NDepend is a tool that simplifies managing a complex .NET code base.
So in other words, (also on the web site)
Architects and developers can analyze code structure, specify design rules, plan massive refactoring, do effective code reviews and master evolution by comparing different versions of the code.
Out of my experience, I know - I really know - that bad designed software is a nightmare to maintain. Worsted of all is that most of the time is it horribly coded and badly documented. I've done seen in the past, and I am still struggling today. It's easy to guess where the problems are, or how you could make the application better. Because guessing is most of the time not the proven to be good, scientists created something like "metrics".
Metrics measure your software, code base or even your software design. NDepend uses these metrics and also the dependencies between your assemblies to tell you more about your application.
More about NDepend later!