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.