Some information from the help file:
Code metrics is a set of software measures that provide developers better insight into the code they are developing. By taking advantage of code metrics, developers can understand which types and/or methods should be reworked or more thoroughly tested. Development teams can identify potential risks, understand the current state of a project, and track progress during software development.
Lets see if I can figure out if one implementation is better than the other with the help of this Code Metrics feature.
I've used a few UI [WinForm] applications with the use of different patterns and implementation styles. This UI has got some basic functionality: lookup employees, show employee, show / hide controls and values... [very very very basic].
First implementation: Visual Studio Drag and Drop.
This one uses the basic designer functionality with double click on a button and implement the logic.
The Code Metric Report looks like this...
The WinForm implementation, where all the logic is has a low Maintainability Index this means Not Good.
The Cyclomatic Complexity, which shows the number of different code paths is the highest in the Employees class because I have put there some If-ElseIf-Else construction for the lookup functionality, it's more a kind of Mock class, so not important.
Depth of Inheritance is the amount of class inheritances, the higher the number the more difficult it is to understand the code. As aspect the WinForm implementation has the highest number because it has allot of inheritance from different .NET framework classes.
Class Coupling, measures the coupling to unique classes through parameters, local variables, return types, method calls, generic or template instantiations, base classes, interface implementations, fields defined on external types, and attribute decoration. Good software design dictates that types and methods should have high cohesion and low coupling. High coupling indicates a design that is difficult to reuse and maintain because of its many interdependencies on other types. So the implementation of the WinForm has a high coupling, not really good for re-use.
Lets see what happens when we play around with this design, move the generated events and let them point the same methods, for example the textbox validating events and the show hide functionality.
For sure the report must show that this implementation has less Lines of Code and the maintainability index should rise [little bit]...
Now I will remove the employee lookup functionality to some kind of controller. It will slowly transform to some kind of Model-View-Controller implementation.
What will happen with the report? there is one more class :-) and we moved some functionality from the EmployeeForm to the controller class. So the maintainability of the EmployeeForm should decrease
I'm wondering why the delegate from the controller are shown in the report, probably because they are separated classes in IL.
The maintainability increased with five points and one another nice thing... we have less code! that's good that means less testing ;-). One thing is to bad, the Class Coupling increased a little bit, that's because the EmployeeForm knows about the controller in this implementation and the controller knows about the EmployeeForm. Lets change that in the next implementation.
I'm going to use an adapter pattern together with the command pattern. This will bring us some more functionality [the possibility to implement "undo" and "redo" in the EmployeeForm, in the previous implementation there was also some extra functionality... that implementation made it possible to expose events to the EmployeeForm that wasn't possible in the other implementations] and decoupling the EmployeeForm from the Controller class.
We now have allot more classes [adapters and commands] so I think... more Code Lines but definitely less Class Coupling and hopefully a better maintainability.
hmmmm... strange less code lines, I must count them by hand and the maintainability of the EmployeeForm increased, not what I expected... there is more logic in the EmployeeForm now it must have the logic to couple the commands to the adapters, but the overall maintainability increased and the class coupling decreased as I thought.
Just one more try to get a better one, a MVP implementation with more interfaces.
I used an interface to decouple the View from the Presenter [I used the MSDN example for this implementation]. the best thing of this implementation is that everything turned GREEN . The use of interfaces for decoupling will help allot :-)
Happy analyzing ;-)