NDepend is a Visual Studio add-in designed for intense code analysis with the goal of high code quality. NDepend uses a number of metrics and aggregates the data in pleasing static and active visual reports. My evaluation of NDepend will be broken up into several different parts.
In the first part of the evaluation I looked at the installation for the add-in. In this installment I cover my first impressions resulting from the initial profiling of the solution that I use throughout my evaluation. The next part will cover some of the individual features of NDepend.
Starting After Installing
The NDepend add-in starts with Visual Studio automatically. The visual indication that the add-in is running is a circular icon displayed at the right edge of the Visual Studio status bar. The appearance of this icon changes as the state of the add-in changes.
The options of the icon also change. You have few options before you load a solution. These options include the ability to open an existing NDepend project or analyze assemblies. Once you load a solution you can create or attach an existing NDepend project.
Selecting the option to attach a new NDepend project displays a dialog that lists the projects in the solution that are built. I can see this dialog being potentially confusing for users that aren’t experienced with profiling or code analysis tools. This is especially true if you haven’t built the solution and the list is empty.
The requirement for the assemblies to be built is spelled out in the topical documentation. Unfortunately, the help within NDepend does not follow any common convention. It cuts its own trail by providing a paragraph or two in tool tips sprinkled over the user interface (just look for the tiny “I” icon). Online documentation for the application exists, but it’s not available here. The documentation experience is not consistent.
Running the Analysis
Typically, you won’t need to do anything special to run the analysis. Just click OK and several things happen almost immediately. The NDepend Error List window is displayed, you get a warning from Visual Studio that your solution was changed outside the environment, the NDepend Report is rendered in your browser, the CQL Query window is displayed, and the NDepend Beginner dialog appears above them all.
The beginner dialog seemed like the place to start, but its few options don’t seem like the best place to start. Therefore, I skipped it and jumped right to the report. The first thing I did was click the link labeled “For beginners: Where to start” at the top of the document. The link opens a pop-up that provides useful information on starting your optimization. I spent a good deal of time combing through the metrics and statistics on the report. Don’t miss the navigation menu at the left that branches to different pages within the report! It was a handy addition to include the query that was used for the CQL rules sections. I’ll talk about CQL in the third part of the review.
There is a lot of information in the report. And thankfully there really isn’t any filler – almost everything is useful. Some of the rules can be subjective, but I would rather start out with a restrictive set and tweak it as needed. Here’s a tip, although it may not be immediately clear, it’s easy to adjust what rules you want in your analysis by unselecting them in the CQL Explorer (not to be confused with the CQL Edit window).
Overview of the Features
Most of the meat outside of the report is available from the NDepend menu. Besides the numerous project options you have access to all of the special windows, searching, and comparison. There is a lot crammed in that menu and its submenus (I counted 50 items in a quick count).
A lot of work is put into providing graphical displays that provide context for the code analysis metrics. Available real estate is the enemy. Luckily, there are menu options for each of these tools that allow the results to be in a full-screen window. I recommend that you use the full-screen versions unless you are running at a crazy resolution. I’m running at 1600x900 and tools like the Dependency Matrix were too constricted when displayed as a page. In my case that was due to the height.
I’ll talk about these tools a little more in the next part of my review, but my favorite is the Dependency Matrix. I could spend hours with this tool tracking down small quality deficiencies! This window will likely dominate my second monitor a good deal of the time.
One annoying thing that should be easy for the NDepend developers to fix is that the CQL Edit window is displayed every single time you load a project. This happens even if you’ve closed it in a prior session. It may seem petty, but it’s a reminder that something is there instead of providing a seamless experience.
Please stay tuned for the next part of my evaluation. I’m going to talk more about the Dependency Matrix, Dependency Graph, and explore CQL.
Disclaimer: Patrick Smacchia contacted me about reviewing NDepend. I received a free license in return for sharing my experiences and talking about the capabilities of the add-in on this site. There is no expectation of a positive review elicited from the author of NDepend.