Updated: Roslyn Metrics extension

Roslyn seemed to be a good choice…

The Roslyn compiler API has evolved over time… the latest pre-release available on Nuget performs way better than the CTP published almost two years ago, so I decided to continue working on my metrics calculator that is based on Microsoft´s new compiler API. In addition to the initially implemented metrics, like maintainability index, cyclomatic complexity, depth of inheritance, class coupling and lines of code, I added a bunch of other metrics. For instance, lack of cohesion of methods (a metric that can be used to find poorly cohesive types), the number of overloads of a method, the number of lines of comments and some other low-hanging fruits likes counters for fields, method parameters, methods, types and so on…

The Roslyn metrics extension does not analyze compiled assemblies, instead syntax- and semantic models are used to aggregate information right from the source code. In my opinion, this has some significant advantages, because calculated metric results are closer to the code typed by the developer (since the code is not optimized by the compiler). It´s also possible to calculate metric results even on projects which do not compile (for instance, due to missing third-party assemblies or any other kind of build dependency).

Calculating metrics on non-optimized (as typed) code also allows the definition of metrics which put code readability more into focus. For instance, I could imagine a metric that finds all variable declarations in a method, which could be moved closer to their usage, which is something that drastically improves readability and stability, because narrowing the scope of a variable can help to prevent situations where a variable has not been set to a valid instance or value. The purpose of the lines of comments metric (as already implemented) is obvious, I think… comments are adding noise to the code, which has a poor impact on readability (apart from that, comments are usually not more than a pack of lies). Code containing comments might also hold potential for refactoring.

Anything else? Yes. Now, the metrics calculator is also available as a standalone application, so it´s possible to use the tool in a CI build environment. The download can be found at http://bit.ly/roslynmetricsutil

Advertisements

Published: Code Metrics Viewer 2012

I published updates of all my Visual Studio Gallery contributions. Actually, there´s no new functionality in there, just minor changes, a few bug-fixes and updated references to third-party libraries. I changed the names of the tools a bit; “Code Metrics Viewer” has been renamed to “Code Metrics Viewer 2010” and the pre-release of “Code Metrics Viewer 2” is now named “Roslyn Metrics“, which makes more sense since I created the Code Metrics Viewer 2012 extension that integrates the Code Metrics Power Tool 11.0 into Visual Studio 2012.

As I wrote in my last post, the Code Metrics Power Tool 11.0 does not have a setup… but don´t worry (-: After you´ve installed the Code Metrics Viewer 2012 extension, just open the Options dialog, navigate to Code Metrics, then Tools – and click the “Download and Install…”-button. This will download the Power Tool from http://bit.ly/11b4mqX and extract it to the local FxCop-directory. If you´re interested in how the setup routine works, you can take a look at the code that I published on Github…

Code Metrics Viewer 2012 Options Dialog

Code Metrics Power Tool 11.0

Some weeks ago, Microsoft released the Code Metrics Power Tool 11.0 that works together with the latest FxCop binaries of Visual Studio 2012. What a surprise… I did not expect that they would come up with a new version of the tool, due to the fact that the code metrics analysis feature is now also available in Visual Studio Professional (of course I know it´s intended to be used in an automated build environment). Even though I implemented my own metrics calculator based on the Roslyn September 2012 CTP, I will integrate the Power Tool into the Code Metrics Viewer 2… thinking about to move the experimental Roslyn stuff into a separate package. Will see…

For god´s sake! I would like to know why the Power Tool does not have a user-friendly setup? It is compressed into a self-extracting cabinet file. In my opinion, this would be okay, if the package would also contain all dependencies which are required to run the application. This would allow to install it to a directory free of choice. But no, the Metrics.exe binary is tightly coupled to Visual Studio binaries and must be copied to the FxCop directory within the Visual Studio installation folder (at least this is mentioned in the installation instructions on the download page). So, before I do the integration, I need to think about a setup util…

I wrote some sample code that can be used to build a simple setup application: http://bit.ly/10kQMQj

Update, 2013/09/20: The Code Metrics Viewer 2012 extension is now available at http://bit.ly/19kOHUI.

Code Metrics Viewer 2 CTP

I published a pre-release version of the Code Metrics Viewer 2 extension targeting Visual Studio 2012. It´s the continuation of my first contribution, but it works completely different. The first version was just a user-interface that integrated the Code Metrics Power-Tool 10.0 into the development environment, but the new version brings its own calculation functionality – and instead of analyzing IL it acts on the source code. The current release supports metric calculation for C#-projects, but functionality supporting Visual Basic is on schedule.

The extension is dependent on the Microsoft “Roslyn” CTP (September 2012, v1.2), which need to be downloaded and installed separately. Because I wasn´t sure, if I am allowed to distribute the Roslyn binaries, I decided to exclude them from the extension package and defined a dependency to the Roslyn Components instead. The Extension Manager will show the following dialog to you if the required package dependency is missing.

roslyn-alert

The download can be found at the Visual Studio Developer Center: http://bit.ly/YujBX8 or on NuGet: http://bit.ly/WheTeO. If the components will be removed after installing the extension, calculation of metric results isn´t possible and the following error message will be shown: “The calculation of metric results has failed. Couldn´t find the Roslyn CTP components.”

missing-roslyn

Small things, big impact (-:

Howdy! A new release is available. You can now open the Code Metrics Viewer from within the Solution Explorer; just right-click the solution node, there you´ll find the “Code Metrics Viewer” menu item…

The configuration of the Code Metrics Tool Path is now a bit easier… if you have successfully installed the Code Metrics Power 10.0 you can use the “Locate Metrics Tool Path”-button in the options dialog to obtain the installation folder automatically.

Hope you enjoy the new features (-:

Is it possible to compare metric results?

Yes, it is! The latest version of the extension has basic comparison functionality. I thought this could be very helpful if one would use the extension during code review and/or refactoring. When I used the tool during refactoring, I had the problem that it was hard to see, if values were getting better or worse. So, I thought it would be nice to load a previously calculated report and compare the data against the latest results, to be able to show some kind of “trend” within the grid. This is one of the features I wanted to wait with until the end of this summer because there is still some work to do… in other words, by now it´s not perfect :-) In some situation the comparison might not work…

I calculated metrics for a very simple console application… Here you can see the Main()-method of the static Program-class, which has a maintainability index of 57. Of course, this is still okay, but it could be better…

So, I made some refactorings to the Program class… I created two new methods named ExtractPublicKey() and WriteKeyFile, recompiled the assembly and calculated the metrics again…

Now I can use the compare feature, to see if I made some “good” progress :-) As you can see in the screenshot, there is a new button named “Compare…” in the toolbar. If you press that button, a file dialog will show up, where you can select the candidate report for comparison. If you want to work with the compare feature I recommend to enable the auto-save functionality in the options dialog – so, a new report will be stored in the solution folder, each time you calculate code metrics.

In my example, I have chosen the report, which was calculated before I did the refactorings – and I see, that the maintainability index increased by 7.

By the way… if you like the tool, I would be glad if you would rate the tool with five-stars in the Visual Studio Gallery :-)