Saturday, April 28, 2012
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.
In the last few months I put together a review of the add-in in three parts. In this article I wrap the review up and provide my conclusion and recommendation.
Go here to get caught up: Part 1 | Part 2 | Part 3
Good and the Bad
No review would be complete without the obligatory like-dislike list. The first three parts of the review are focused on the software. With this article I bring in the whole picture based on my experiences.
| Good - Visual tools
- Performance
- Support response time
- Price
| Bad - Documentation
- VS Integration
- No installer
|
Bad
I’ll start with the bad, because overall my assessment of NDepend is positive.
Documentation is important for me. Some people rarely if ever look at documentation. I like to dig through the documentation. It’s a stylistic way of learning and I’m not alone. NDepend does have documentation. Unfortunately, the implementation is inconsistent and is often comprised only of short tool tips. Sometimes these tooltips aren’t easy to notice and going on an Easter egg hunt for them is not my idea of fun.
The integration of NDepend into Visual Studio needs some polish. This is likely due in part to poor documentation and guidance from Microsoft on integrating into Visual Studio. The point of documentation is sort of ironic. However, the point exists that other tools integrate better into Visual Studio. My biggest complaint is windows such as the CQL Edit Window not remembering their state.
The subject of the installer is not major. However, installers are expected in this day and age. I can let this pass for applications like Eclipse, but not a professional, commercial application like NDepend. I have a certain level of comfort with knowing an application is being installed to a permissions restricted area consistent with other applications on my computer. I can do all of this myself, but I have better things to do.
Good
The visual tools are amazing. The report is the meat of the application, but the tools are the dessert. Without the tools I would have lost interest in using NDepend. My favorite is the Dependency Matrix just in case that hasn’t been made clear yet.
I haven’t mentioned performance in my evaluation so far, because it hasn’t been an issue. I have not benchmarked builds with and without the tool. Undoubtedly there is some cost to the analysis that is being run, but it’s not enough for me to care.
In my evaluations I’ve also avoided talking about anything outside of the actual tool itself. I cannot speak to the sales experience, because I didn’t purchase the tool myself. However, I’ve raised a few questions with NDepend support since I started evaluation and the responses have been fast. I have no reason to believe that my support experience is any different than others, but it’s possible.
And finally price. I purposely didn’t look at the price of the tool until writing this conclusion article. I feel that knowing the price changes the expectations and I wanted my expectations to be solely what I would expect out of a performance code analysis tool. I was happy to see that the price is fair, and just as importantly the licensing is easy to understand.
The Skinny
NDepend exceeded my expectations. I went into the evaluation skeptical as is my nature. I knew when I accepted the offer to evaluate the tool in exchange for a license that I was taken on the responsibility to give it a fair shake. I take that responsibility seriously. And I’m pleased to say that after using this tool it will be something I continue to use and recommend others to use.
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.
Monday, April 09, 2012
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 installing the add-in. And in the last part I went over my first impressions including an overview of the features. In this installment I provide a little more detail on a few of the features that I really like.
Dependency Matrix
The dependency matrix is one of the rich visual components provided with NDepend. At a glance it lets you know where you have coupling problems including cycles. It does this with number indicating the weight of the dependency and a color-coding that indicates the nature of the dependency.
Green and blue cells are direct dependencies (with the difference being whether the relationship is from row-to-column or column-to-row). Black cells are the ones that you really want to know about. These indicate that you have a cycle. That is, type A refers to type B and type B also refers to Type A.
But, that’s not the end of the story. A handy pop-up appears when you hover over the cell in question. It explains the color, the dependency, and provides several interesting links that will teach you more than you want to know about the dependency.
You can double-click the problem cells to explode the dependency. That will show the dependencies on a method-by-method basis allowing you to more easily target and fix the problem. When you’re done you can click the back button on the toolbar.
Dependency Graph
The dependency graph is another component provided. It’s complementary to the dependency matrix, but it isn’t as easy to identify dependency issues using the window. On a positive note, it does provide more information than the matrix.
My biggest issue with the dependency graph is determining what is shown. This was not readily obvious. I ended up using the navigation buttons to get an acceptable view. I would have liked to choose what I see.
Once you see the types you want you can get a decent idea of coupling strength based on the width of the dependency lines. Double-arrowed lines are problematic and are shown in red. The size of the boxes will be related to the metric being displayed. This is controlled using the Box Size drop-down in the toolbar. Personally, I don’t find the size of the box to be helpful, so I change it to Constant Font.
One nice thing about the display is that you can see the entire path of dependencies when you hover over a type. This is done by color-coding the dependencies and dependants. It would be nice if selecting the box for the type would lock the highlighting in place.
I did find a perhaps unintended work-around to the color-coding. You can lock the color-coding in by hovering over the type, right-clicking, and then clicking on the canvas area to clear the pop-up menu. You can then do whatever with it including saving it to an image file with the color-coding.
CQL
NDepend uses a code query language (CQL) to work with your code just like it was a database. CQL cannot be confused with the robustness of T-SQL or even LINQ, but it represents an impressive attempt at providing an expressive way to enumerate and interrogate your code.
There are two main windows you’ll use when working with CQL. The CQL Query Explorer allows you to define what queries (rules) are run as part of a report – I immediately unselected rules that I don’t want in my results. The CQL Query Edit window is where you can view or author your own rules. The explorer window is pretty self-explanatory, so I won’t mention it further other than to say that any queries you author will appear in the custom group.
Authoring your own queries is really hard to screw-up. The Intellisense-like pop-ups tell you what you can do while making composition easy. I was able to create a query within two minutes of playing with the editor. My query warns if any types that are interfaces don’t start with an “I”.
WARN IF Count > 0 IN
SELECT TYPES
WHERE IsInterface AND !NameLike “I”
The results from the CQL Query Edit window are immediate. That fact makes it useful for ad hoc querying. It’s worth mentioning two things that could make the experience smoother. First, out of habit from using Visual Studio I expect to be able to scroll and press Tab to select an item in the list (like Intellisense). You have to press Enter when you scroll to the item you want. Second, the commands are case-sensitive. I don’t see a really good reason to enforce that.
CQL has a lot of potential not just in enforcing code quality, but also enforcing architectural constraints that your enterprise has defined.
Up Next
My next update will be the final part of the evaluation. I will summarize my experience and provide my conclusions on the NDepend add-in.
** View Part 1 of the Evaluation **
** View Part 2 of the Evaluation **
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.
Tuesday, March 13, 2012
I recently deployed an MVC application to our production Windows 2003 Server and received an error that plagued me for longer then I care to admit. The error manifested when the Infragistics data grid attempted to render. The header would render, but the data area was empty and the waiting icon appeared and stayed.
The script error associated with the problem is:
The remote request to fetch data has failed: (parsererror)
'JSON' is undefined
It turns out that the default compatibility settings in Internet Explorer 8 (IE8) have Intranet applications put into compability mode. That essentially sets it to run as IE7. Therefore, the application wouldn't work right, because IE7 doesn't have support for JSON.
Here's how to fix it:
- Click Compability View Settings from the Tools menu
- Unselect Display intranet sites in Compatibility View
- Click Close
Tuesday, March 06, 2012
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.
Up Next
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.
Thursday, February 16, 2012
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.
The first part of my evaluation of NDepend is in the installation. The second part will cover my first impressions including the initial profiling for the solution that I will use throughout my evaluation. I used version 3.0.9 Professional in my testing.
I posted this first part of my evaluation in late 2010. However, personal issues kept me away from continuing my evaluation. Finally, I'm getting back to the evalution. I've reinstalled the add-in and I've made changes to my original post here where they are applicable.
Installation
I was given an XML file and pointed to a location to download the ZIP file containing the files. The first thing I noticed is that there is no installation program. The decision was made to use XCopy deployment. Personally, I think this is the wrong decision and when I sent a message to Patrick Smacchia he responded with a link to a discussion about this topic. Apparently, this is already a well covered issue that people have with this tool.
The people on the side of using XCopy deployment have some valid points; however, the highlighted point in the discussion is completely illogical. In it, the developer makes the comparison between having a Ferrari with an automatic transmission and an application with an installer. I had to shake my head at that and just move on.
Given that XCopy was my only choice I created my directory and unzipped the files to it. You also need to copy the XML file into the new directory although it's not indicated in the documentation. The first file you'll want to look at is the quick start file (named QuickStartTutorial_NDepend.txt in my version). This file will guide you through the additional steps for setting up the add-in.
The next step will be run the add-in executable (named NDepend.Install.VisualStudioAddin.exe). This executable will perform the integration into Visual Studio. The version I tested supports 2005, 2008, and 2010. The tool is easy enough to use with simple Install and Uninstall buttons for each supported version of Visual Studio.
The tool also provides an option for Full Integration or Light Integration. There is no dedicated documentation for this tool or NDepend. Instead, tool tips are provided on special icons. Tool tips just cannot store enough information to make an informed decision. For instance, for Light Integration the tool tip says you won't have access to "all VisualNDepend panels in Visual Studio", but it fails to enumerate either what is missing or provided at that level. This is probably not a big deal, because most people are going to want Full Integration. My installation and therefore my evaluation is based off of the Full Integration.
It's also worth noting that there are two tools called Visual NDepend and NDepend.Console that you get. These applications allow you to perform code analysis outside of Visual Studio. Some people may prefer that based on some of the resource requirements of NDepend (which I'll get to in Part 2 of my evaluation that covers my first impressions).
All-in-all the installation was simple enough to justify XCopy deployment; however, I cannot shake the idea that it would seem that much more professional with an installer that would combine several manual steps into a single step. The space required for the installation is slightly above 21 MB.
** View Part 2 of the Evaluation **
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.
Resources:
Debate on using XCopy deployment with NDepend
Monday, December 12, 2011
It's been a long time since I've done a post or had any motivation to do so. Much of that is due to events that turned my life upside-down for a time. However, I can concentrate on other things now that I'm shaking off the shackles and things are looking brighter.
With that in mind here are a couple of random tips for Visual Studio. These tips work specifically in Visual Studio 2010; however, it's possible they may be relevant to past and future versions.
Tip #1: Editor does not work correctly for CSHTML files
I frequently have the issue where backspaces and carriage returns stop working when I'm editing a CSHTML file. This appears to be a common bug in Visual Studio. The quickest way that I've found to temporarily resolve the bug is to go to a CS file (which I have open anyway), save it (whether it needs it or not), and then go back to the CSHTML file. At that point I have the use of those keys again.
Tip #2: Getting rid of the pesky validation errors for HTML 5
MVC 3 by default uses HMTL 5 markup. This includes tags such as section, header, and footer. Visual Studio by default uses a much older standard for validation. Therefore, you will get a bunch of warnings/errors such as:
Validation (XHMTL 1.0 Transitional): Element 'section' is not supported.
You can easily change the target for the validation in the Visual Studio options. In this case, I use the HTML 5 option in the HTML Validation settings. The path to this is: Tools > Options > Text Editor > HTML > Validation. Select the target from the drop-down list and then click OK.
Thursday, February 17, 2011
 |
I was honored today by the receipt of a 2011 Microsoft Community Contributor Award. Thank you to Microsoft and anyone involved in the nomination and award process.
|
Friday, January 28, 2011
In a previous post I reported an InvalidProgramException that occurs in a certain circumstance with unit tests involving accessors on a private generic method. It turns out that Bug #635093 reported through Microsoft Connect will not be fixed.
The reason cited is that private accessors have been discontinued. And why have private accessors been discontinued? They don't have time is the reason listed in the blog post titled "Generation of Private Accessors (Publicize) and Code Generation for Visual Studio 2010".
In my opinion, it's a piss poor decision to discontinue support for a feature that they're still using within automatically generated unit tests against private classes and methods. But, I think what is worse is the lack of guidance cited in the aforementioned blog post. Their advice? Use the PrivateObject to help, but develop your own framework.
At the end of the day what Microsoft is saying is, "I know you spent a lot of money for this product. I know that you don't have time to develop a framework to deal with this. We don't have time and that is all that's important."