Put a Little NDepend in your Visual Studio
Editorial Note: I originally wrote this post for the NDepend blog. Check out the original here, at their site. If you like posts on the topics of static analysis and software architecture, check out the rest of the posts while you’re over there.
The software development world is filled with what I think of as “Coke-Pepsi” debates. This is how my brain categorizes debates over preference that are almost entirely subjective. There is no right or wrong answer to “is Coke or Pepsi better?” The answer is, “whichever one you like better.”
Examples abound in the software world. Should you use a heavyweight IDE or a lightweight text editor? Which OOP language is ‘the best?’ And, speaking of OOP, should you use an OOP language at all, or should you use a functional one? Pascal casing or camel? The list goes on, but these sorts of things generally boil down to the comfort and preferences of the person or team.
It would be tempting to paint NDepend Standalone versus NDepend’s Visual Studio plugin with this brush. And, while I think you could make a pretty legitimate case that this too, is simply a matter of preference, I’d like to do a thought exercise today in which I lobby in favor of the integration approach. In my opinion, there are enough advantages that I might be able to sneak this one out of the Coke-vs-Pepsi realm.
What’s The Difference?
First of all, I should probably explain a bit more about the difference. NDepend standalone runs like any standard, windows desktop application. In order to use it, you’d launch it and use it to query your code base, run reports, visualize your architecture, etc. If you wanted to modify your code and use NDepend simultaneously, you would have two open Windows that you would alt-tab between.
As a plugin, NDepend runs as if it were a part of Visual Studio itself. Visual Studio has a plugin-supportive architecture that allows third party tool authors to write plugins that behave this way. To users of the plugins, the integration is totally seamless. So for all intents and purposes, NDepend’s Visual Studio plugin makes NDepend a first class part of Visual Studio. Thus everything you do with NDepend and your code all happens in the same place: Visual Studio.
Why Is This Better?
I’d imagine the first thing that occurs to you is the lack of needing to alternate between two windows. And I submit that this is, in fact, an advantage, though this advantage only scratches the surface. Logistically, there is less friction in use when you don’t need to constantly context switch between two windows. And, even if you prefer to separate the concerns out into multiple windows (say, if you have multiple monitors), you can still do this inside of Visual Studio.
But the advantages run deeper and subtler. The friction that occurs with context switch isn’t just a simple waste of brain cycle and time. It also creates a natural disincentive to use the functionality. A micro-decision of “nah, not worth it” might be the response to “should I open NDepend to check whether this class has any analysis-related problems?” That same decision might have been “yeah, I’ll do that,” if NDepend were integrated into Visual Studio and you could make it happen with a keystroke. Aggregated over a lot of time, the person with the plugin will wind up getting a lot more mileage out of the tool, making it a better return on investment (ROI).
Also to consider is the effect of the feedback within the environment itself. People that write their code in Visual Studio are used to looking at the output pane and the pane with compiler warnings and errors to get feedback about what they’re doing. The NDepend plugin supplies feedback in this familiar form. Both the warnings and the code query results appear in familiar panes to which developers are accustomed to looking. It is not much of a leap at all to add “check for NDepend code warnings” to “check for compiler warnings.
And finally, adding NDepend to the Visual Studio experience conveys an important message about static code analysis. If you have a build report about code quality or you use some external tool to run analysis on the code, that suggests that analysis is something you do to the code, after the fact. But when baked into Visual Studio, developers get the idea that static code analysis is a first class part of the software development experience.
It’s no coincidence that, with each new release of Visual Studio and other IDEs, like Eclipse, more and more static analysis tooling comes with it, out of the box. The experts that make the IDEs recognize the value of this tooling. I encourage you to do the same.
To be clear, if you’re using static analysis to help you boost code quality, you’re way ahead of the game whether or not you’re integrating with Visual Studio. Static analysis should be an integral part of your approach to your code, and if you use standalone NDepend to do that, then great! I’m just writing this because I think you could get a little bit more mileage out of your investment if you went for the full integration with Visual Studio. Maybe it is like Coke vs. Pepsi, but I tend to think it’s more like getting a full glass of soda versus a nearly full glass.