Author: web   Add date: 04/08/2008   Publishing date: 04/09/2008   Hits: 0

---

Cyclometric complexity, depth of inheritance… these are terms that many developers paid very little attention too once their software engineering paper at university was finished and they were baking in the final summer before heading off into the “real world”. Now, in Visual Studio 2008, these terms are back with the new code metrics engine.There is a reason that Cyclometric complexity and other such metrics are taught in university – they are often great indicators of just how maintainable a software project is. Before digging in deeper and looking at these metrics one by one, how can you generate these metrics?Open a solution in Visual Studio 2008, and under the “Analyze” menu, select “Run code analysis on ”. After a short while you will be presented with a snap in pane much like how everything in Visual Studio is presented. Resizing this pane, you should see something similar to the following:Maintainability IndexWe can see in this solution that the Designer project has a maintainability index of 80. A maintainability value is a figure between 0 and 100 where 100 is fantastic and zero means you should probably change your profession :-) A color indicator gives an instant indication of what this values means – green is universally accepted as “good”, red as “bad”. So far so good but is there anywhere that is causing concern? Setting the filtering to find anything below a value of 20 we get a single result. Drilling in we can find exactly where that code exists:By double clicking the row we are taken directly to the code that is at fault and, surprise, it’s the automatically generated code that Visual Studio makes for initializing a form! While it’s not the best code in the world it’s at least reliable and it’s not something we actively have to maintain so we can safely ignore that method.More information on how this value is calculated can be found on the Microsoft Code Analysis Team Blog here.Cyclometric complexityCyclometric complexity is a well known way of calculating how complex code is. We won’t go into detail here about exactly how to calculate it yourself but I would recommend checking out Wikipedia for more information. A lower figure for cyclometric complexity is important and testing this value is now included in FXCop, the built in static analysis tools for visual studio meaning that warnings may be generated if the cyclometric complexity of a method goes beyond a healthy level. Depth of inheritanceThis metric gives a quick indication of how many layers of code there are forming an object. For example, if class A inherits class B then class A has a depth of 2. Understandably, once code inherits back too far it can become quite cumbersome trying to maintain that code – a change at one layer may have an impact on code elsewhere. One thing to keep in mind with this metric however is that it examines the entire .Net framework. What I mean here is that if you inherit, for example, off System.Windows.Window, you will get a reasonably high figure immediately because of the inheritance depth in the framework. This diagram from the Microsoft Code Analysis Team Blog shows how depth of inheritance is calculated:Class couplingThis metric provides a figure of how many classes that a given project, class or method relies upon. It only takes account of the class itself and not the sub classes in the inheritance hierarchy. As with the depth of inheritance, less is best.Another diagram from the Microsoft Code Analysis Team Blog helps explain class coupling:Lines of codePossibly one of the less useful metrics, lines of code was once looked upon as a key metric of how large a software development project was. The truth is that the lines of code is often a misleading figure as you can have a lot of lines that do very little or very few that do a lot (and a mix of the two). How lines of code are counted is also up for debate – should you include whitespace? What about lines that do not equate to direct code like “{“? The engine for calculating lines of code in Visual Studio is reluctant to count anything that isn’t a line of code that will evolve into executable code. This means the figure may be lower than the figure presented by other tools.Having said all this, generally speaking, a lower figure is always better if possible – just don’t sacrifice readability to push it lower in every case.Team based developmentThere is plenty of extra usefulness in the code metrics additions in Visual Studio 2008 when it comes to working with your team. The ability to export to Microsoft Excel is useful when needing to send the stats to other team members who might not be developers – project managers for example. If you use Team System you’re also in luck as you can create work items based on the metrics.Visual Studio 2008 is a solid step forward in aiding developers in taking a more holistic approach to software development – rather than just for writing code, Visual Studio now can be used to better understand the interactions of our code and how that impacts the maintainability and robustness of our solutions. I hope this post has helped illustrate what the metrics provided by Visual Studio mean and what value they provide to your development process. If you would like to learn more about code metrics and code analysis in Visual Studio I’d highly recommend reading the Visual Studio Code Analysis Team Blog here.Download Visual Studio 2008 90 day trialFor detailed information and to request a free 90-day trial DVD of Visual Studio 2008 Team Suite to be sent out to you, go to the Microsoft Visual Studio webpage. About the AuthorJohn-Daniel Trask is a co-founder of Mindscape, a product development company based in Wellington New Zealand. He also maintains a popular blog about software development and business.

Prev:Enhanced CSS

Next:At last, some Windows Mobile security certification

Comment:

---

Category: Home -> nokia