Learn Key Bindings
It's an obvious and trivial thing, but the timesaving will add up, especially for those actions you perform tens or hundreds of times a day such as building and debugging. Here are some basic bindings every Visual Studio developer should know:
- Build: CTRL + SHIFT + B
- Word completion: CTRL + SPACE
- Start with debugging: F5
- Start without debugging: CTRL + F5
Even expert Visual Studio developers can benefit by learning new bindings. Download the Visual C# 2008 Keybinding Reference Poster and hang it in your work area.
Generate XML Comments with GhostDoc
Instead of typing XML comments by hand, let a tool do the work for you. Although macros and snippets are reasonably effective for this, I would recommend Ghost Doc over any other solution. This free add-in uses customizable templates to generate consistent, English-readable documentation based on the current context. To use it, right-click (or use CTRL + SHIFT + D) to document the current element. For example:
This generates the following documentation (note GhostDoc split the property name into words and created a sentence from it):
Auto-Implement Properties
Take advantage of a new feature of C#: auto-implemented properties. Rather than creating a private backing field for your properties, let the compiler do it for you. The following demonstrates the syntax:
Use the code snippet to make this even faster. Type prop (the shortcut for an auto-implemented property) followed by TAB TAB. Then fill in the data type and property name:
Refactor
The refactor feature in Visual Studio is indispensable for many tasks, especially renaming, but one productivity feature I particularly like is Encapsulate Field. If you are unable to use an auto-implemented property, declare a private field and let Visual Studio generate the Property for you. To use this feature, right-click on the field and select Refactor > Encapsulate Field...
The property is created for you:
Add Commands to Visual Studio 2008
Install the PowerCommands for Visual Studio 2008 to add several productivity commands such as:
- Close all documents
- Copy and paste a class (automatically renames)
- Remove and sort using statements project-wide
- Copy and paste references (including a project reference)
Install the Team Foundation Server Power Tools to add several TFS productivity commands such as:
- Find in source control
- Open source folder in Windows Explorer
- Work item templates (can be used to set values on multiple work items at once)
Add your own productivity commands. For example, to add Reflector so it automatically opens on the current project.
- Select Tools > External Tools
- Click Add
- Name it Reflector and browse to the executable
- Enter $(TargetPath) for the Arguments
Speed up Compilation with Project Configuration
You may build tens of times during a programming session, so don't enable anything that isn't absolute necessary such as code analysis and XML documentation. Develop in Debug configuration, and switch to Release configuration just before check-in to run code analysis and generate XML documentation. In a large solution I recently worked on, this shaved a minute off compilation time.
The following shows code analysis disabled in Debug configuration:
The following shows code analysis enabled in Release configuration:
Let Visual Studio Generate Unit Test Code
Although it can't fully automate unit testing yet (check out Pex), Visual Studio does a good job of generating positive unit test code to give you a jump start. To use this feature, right-click on an element you would like to test and select Create Unit Tests...
Visual Studio generates the following test method:
Use Interface-Driven-Design
You probably never thought of an interface as a productivity feature, but it can be if your development process is driven by contracts instead of implementation. Let me illustrate with a simplified example. One developer owns the business layer and another developer owns the data access layer, and they need to agree on how to communicate to implement a new feature. In some business object designs, business components will instantiate data components (or call a static method). This is a problem from a design standpoint because the two become tightly coupled. It is also a problem from the productivity standpoint because the business layer developer becomes dependent on the data access layer developer's implementation. Interface-driven design (IDD) solves this issue.
Rather than the business component developer waiting on the data component developer, they meet to design and implement the interface. Both developers are then free to go their separate ways and implement the components in parallel. IDD also enables the business developer to mock the data access component, thereby removing any scheduling dependencies. The following illustrates the design:
Make a Mockery of Dependencies
Different developers may own layers or features that your component is dependent on, but don't let that slow you down. Suppose you are responsible for the business layer which depends on the data access layer which in turn depends on database tables and stored procedures. Rather than waiting for dependent layers to be completed, mock the data access layer so you can implement and unit test the business layer. By the way, you should be using mocks anyway; otherwise your unit tests are more than likely integration tests. I recommend Rhino Mocks.
Here is a sample unit test with mocks:
Data Drive Unit Tests
If you have a unit test that multiple inputs to fully test, you could write a test method for every possible combination, but data-driven unit tests are more efficient. When the unit test is run, it loads data from a table and calls the unit test for each row. You can access the data in the current row using the TestContext.DataRow property.
Once the test completes, you can view the results:
