Visual Studio 2010, Enhance your Jedi Skillz

I’ve blogged about becoming a Jedi in Visual Studio 2008 before.  Being a Jedi in Visual Studio means you focus more on adding value to the software you’re working with and less on the process of the IDE you’re doing your work in.

Visual Studio 2010 has some great features to allow you to do just that.  So much so, in fact, that I can’t possibly do them justice in a single post.  I’ll start with a few here and continue with a few posts on ways to get Visual Studio 2010 to let you write software faster.

All of what I’ve posted about VS 2010 still applies, like Auto Hide Solution Explorer, Toolbox, etc, single custom toolbar, etc.

Use multiple monitors.  VS 2010 has inherent support for multiple monitors.  You could previously get VS to display on multiple monitors; but now the tool windows in VS 2010 can be moved outside the main VS window, and dragged onto another monitor.  This is particularly handy (in my opinion) with debugging.  You can have your watch window on one monitor, the main editor on another monitor ( and if you’re lucky enough to have a 3rd monitor) the application you’re debugging on another monitor.

Use Navigate To.  I’ve been a user of Resharper for many years.  One of it’s features is the ability to Go To Declaration—which allows you to navigate to the declaration of a type (if it’s in your solution, metadata if it isn’t).  Now Visual Studio 2010 has a very similar feature: Navigate To.  This feature can be invoked with Ctrl+, and will pre-populate the form with the type at the caret.  The form lists all the project files and types within the solution that match the text, including config files, CS files, classes, interfaces, etc.  Previously you had to to perform a Find In Files and wade through the false-positives to go right to the declaration of a type.  For example, if I press Ctrl+, and type “Main”, I’ll see the following Navigate To form:


I can then simply press return to go to the declaration of the Main method.

If you are a TDD practitioner, switch to Suggestion Mode.  Pressing Ctrl+Alt+Space toggles between Suggestion mode and Completion mode.  Completion mode is the IntelliSense mode that was in version 2008 and prior.  2010 has a new Suggestion mode that doesn’t auto-complete types when you press space, period, semicolon, etc.  They same types show up in the IntelliSense drop-down; but you can still auto-complete the type it suggested by pressing the down arrow then space, period, semicolon, etc.  For example, if I’m typing test code to test a type named Text, in Completion mode it may auto-complete with “TextBox” when I press space.  In Suggestion mode it will simply accept what I typed when I press space and not auto complete.  What’s nice in 2010 is that IntelliSense now knows about “Text” as a type even though I haven’t declared it, so when I continue and type “text = new T”, “Text” now shows up in the IntelliSense drop-down.  I can have it complete it with “Text” by pressing down-arrow and continue typing.

Use Call Hierarchy to see what code is calling a particular method.  Call Hierarchy is new feature in Visual Studio 2010 that shows you in a tree structure what methods call a particular method as well as what methods a method calls.  For example, if I right-click a call to the UnityContainer constructor and select View Call Hierarchy, the Call Hierarchy form is displayed which shows what calls UnityContainer and what UnityContainer calls.  For each item in a node, you can expand to see what that method calls and what method calls it.  For example, InitializeContainer calls the UnityContainer constructor, if I expand the InitializeContainer entry in the tree I can see what it calls and where it is called from.  If I expand it’s Calls From ‘InitializeContainer’ I can see what other methods InitializeContainer calls.  For example:


Since I last blogged on improving your Visual Studio skills, Scott Cate and Steve Andrews have taken up the Visual Studio Tips and Tricks torch from Sara Ford and are hosting and, respectively.

kick it on

Best Practices

We had a fishbowl session at Prairie DevCon recently, titled “When and When Not to use Best Practices”.  The idea for the session came from a Twitter conversation between myself, D’Arcy Lussier and Shane Shouldice.  That Twitter exchange basically alluded to the sentiment that there is no such thing as a best practice.

Best Practices is not a term used solely in Software Development, and not a term coined by the Software Development community.  Wikipedia defines Best Practice as “…a technique, method, process, activity, incentive, or reward that is believed to be more effective at delivering a particular outcome than any other technique, method, process, etc. when applied to a particular condition or circumstance.” and goes on to detail that “[a] given best practice is only applicable to particular condition or circumstance…”

There were some great participants in the session, and the overall sentiment echoed that of the twitter exchange: people’s frustration with how “best practices” have been adopted by other members of the software development community.  The major issue is that developers blanketly implement best practices without putting any thought into the appropriateness of the practice in their context.  This, I think, stems partially from the source of the best practice and the adeptness of the consumer of the best practice.

While I don’t think we can really expect to get away from “Best Practices” as a term in our industry, I think we can go a long way to improve people’s understanding of what a “best practice” is.  Some important things when documenting Best Practices: there is a context in which they are appropriate, they are not fixed procedures.  And for consuming Best Practices: be sure you understand the context in which the practice is intended to be used.  Also, don’t be afraid to put some thought into your use of the practice; if it doesn’t quite fit in your circumstance change it or move on to another practice.