There are no comments yet...Kick things off by filling out the form below.
Code Metrics for BlogML 2.0
A short while ago I announced the partnership between BlogML and NDepend tool as a static code analysis tool that lets .NET developers analyze their code and improve it.
I also used BlogML 2.0 code to write a review about this tool on DotNetSackers community that you can read here.
I thought it would be interesting for our users and other .NET developers to read about some code metrics of BlogML 2.0. You know that BlogML 2.0 has been the most stable version of BlogML and its .NET library has been a good example of a very well-designed component for .NET 2.0 that can run easily on Mono (to be ported to Linux and OS X) and has a very simple and clean design.
Hopefully I will publish a list of code metrics for BlogML 2.5 after its release to let you compare these two builds and see how BlogML is improved between two versions.
It may be very interesting for you to know that whole BlogML 2.0 library for .NET was 395 lines of hand-written code (this is after reducing the number of auto-generated code lines by Visual Studio templates).
Following snap should show you some of the main code metrics for the project generated by Visual Studio:
NDepend gives you some interesting information about BlogML design and code.
Below you see the Visual NDepend diagram for BlogML 2.0 that shows the usage and importance of different classes and methods in the code.
The other diagram that proves the good and simple design for BlogML is Abstractness vs Instability diagram that shows the BlogML design at the middle.
NDepend also helped me figure out some problems with our code and design.
One of this problems is the lack of enough code comments that will be solved in BlogML 2.5. The other problem is the existence of some methods with too many arguments that isn't acceptable from a framework design view and this will be solved in BlogML 2.5 as well.
the other important point is about the size of some types. BlogMLPost is a large type that should be reduced somehow because this point is so important for us. The size of BlogML files and BlogML instances in memory does matter for us very much because for real world scenarios and some blogs with many posts this can provide some troubles when moving the data.
There are many more great information that NDepend has given to me to consider them for next version. It's not easy to improve the overall design for BlogML 2.5 but my plan is to start the process in BlogML 2.5 and get it done in BlogML 3.0 to have a good design. We need some basic changes in BlogML design that has been with it from the earliest version so probably BlogML 2.5 breaks the support and compatibility for previous versions both in specification and in .NET library.
