JetBrains .NET Tools Blog

If you haven’t done so yet, check out Ilya Ryzhenkov’s blog for some insight concerning ReSharper 4.5. Scheduled for release in early 2009, this new version is supposed to bring support for VB9, core productivity enhancements, and more.

Here’s an update on some recent posts and articles on ReSharper that deserve everyone’s attention.
 

• Brian Di Croce. The Case for ReSharper in the Enterprise - Brian is essentially getting our job done for us! He sets forth a number of arguments for decision makers to prove that ReSharper is not just a fancy toy but a true productivity enhancer.
• James Kovacs. Becoming a Jedi - Part 1 of N - James is working on a series of screencasts to show the power of ReSharper features. The first of them, Becoming a Jedi - Part 1: Code Browsing, is already available.
• Derik Whittaker. ReSharper 4.0 vs CodeRush/Refactor! — Smack Down results - Derik compares ReSharper 4.0 EAP to CodeRush and shows how to make these tools run together smoothly.
• Dale Smith. Tracking Technical Debt in ReSharper - Dale shows a simple way of handling technical debts using one of handy ReSharper features, To-do Explorer

 
Thank you all for your praise, arguments, and remarks!

Thanks for sharing your thoughts and demands in the previous post. Your input will hopefully push us to pay more attention to screencasting in the near future.
 
Meanwhile, in case that you’ve missed it, take a look at our existing collection of demos.

This post serves to gather feedback regarding any particular ReSharper features that you’d like to see reviewed in this blog.
Please have your say!

Updated! This post is not a place to suggest new features/improvements for whatever version of ReSharper. The most efficient way to do it is using JIRA.

Personally, I’ve been a fan of comparison tables for ages, and now there’s one that hits the nail on the head!
 
Ladies and gentlemen, please welcome ReSharper 3.1 vs Plain Visual Studio - face to face, feature to feature!

Of all ReSharper’s features, two are most noticeable: context actions and quick fixes. Along with marker bar, these are exactly what a user sees every time he works with a real-world solution.
 
It’s pretty obvious what these features do - both offer drop-down lists filled with various available actions for modifying your code. However, specific differences between context actions and quick-fixes are not readily evident. Bearing that in mind, we will compare the two features below.
 
Availability of quick-fixes and context actions for a code position is designated by two differently colored bulb icons to the left of current line:

• red for quick-fixes, and
• yellow for context actions.

Whenever both quick-fixes and context actions are available at a specific caret position, a red bulb is displayed.
 
When any of two bulbs is displayed, pressing Alt+Enter launches a drop-down list with all available quick-fixes and/or context actions. If only quick-fixes are available, the list looks like this:

 
If only context actions are provided:

 
If both quick-fixes and context actions are available:

 
Quick-fixes are specifically designed to fix any code with highlighed errors, warnings, suggestions, or unused elements. In other words, wherever you see a code item marked with a red, green or blue curly underline, or a symbol highlighted in grey, you can bet there’s a quick-fix provided. Applying a quick-fix at a specific line can cause code modification in any other corner of your solution. For example, the “Create Method” quick-fix applied upon a call to a nonexistent method causes ReSharper to create the corresponding method after the current method ends or in another class:
 
Before applying:

 
After applying:

 
Another example would be triggering a quick-fix over a method call to modify the type of an argument in the corresponding method declaration, which can possibly reside in another file:
 
Before applying:
(Method call)

(Method declaration)

 
After applying:
(Method call)

(Method declaration)

 
On the contrary, context actions serve to provide ways to change your code instantly. They’re not associated with any discovered errors but displayed merely because they might be useful to you. After all, if you’re looking to surround a string with a string.Format() call or merge two nested if statements, it’s much easier to do with context actions than by hand.
 
Since quick-fixes are tied to the results of code analysis, they’re only applied to C# code. As for context actions, three separate sets of them are available for C#, VB.NET and XML.
 
For both C# and VB.NET, you can explicitly choose which context actions to enable. That can be done using language-specific Context Actions tabs in ReSharper Options. No comprehensive list of quick-fixes is available to a user and you can’t disable quick-fixes associated with compilation errors one by one - however, you can abandon code analysis altogether (to do that, clear Enable code analysis in ReSharper | Options | Code Inspection | Settings). You can also fine-tune the list of displayed warnings and suggestions that have quick-fixes associated with them (ReSharper | Options | Code Inspection | Inspection Severity).
 
For examples of using context actions and quick-fixes in practice, see the following links:

• ReSharper Horizons: Jedi Way - Implementing Members
• ReSharper Horizons: Transforming Conditionals
• Joe White’s Blog: ReSharper, day 17: Change All with Alt+Enter (and, Introducing the red light bulb)

This is not a kind of post that you’d recommend as a source of insight but it’s important nevertheless as we’d like to say a random thank you to all the people who have recently pushed ReSharper to the masses by sharing their positive experience in their posts - this, in particular, applies to:
 
Ben Hall for a prompt independent review of earliest R# 4.0 nightly builds
 
Matthew Cochran, who reviews code cohesion practices and recommends ReSharper for its set of refactorings
 
Casey Charlton for pointing out how responsive R# team members can be at times
 
As well as all of you who announced the advent of the life-giving R# 4.0:
 
Alex de Groot
Arjan Zuidhof
Chabster
Chris Alcock
Chris Brandsma
Darrell Russell
Darren Stokes
David Longnecker
Davy Brion
Einar Ingebrigtsen
Gabriel Lozano
George Barbu
Hadi Eskandari
Jan Van Ryswyck
Jeroen
Matthew Podwysocki
Oren Eini
Rinat Abdullin
Simone Chiaretta
Stefan Lieser
Steve
Steven Harman
Tim Boland
Will Asrari
 
and many others!

ReSharper can reformat an arbitrarily selected block of C# or VB.NET code, all code in the current file, all files in a directory, the current project, or even the current solution, according to options configurable in:
 

• ReSharper | Options | Languages | C# | Formatting Style for C# code, or
• ReSharper | Options | Languages | Visual Basic .NET | Formatting Style for VB.NET code.

 
Once the formatting settings are configured, you can share them with your fellow team members to ensure uniform code appearance.
 
Whenever you have a file opened in the editor, select a fragment that you want to reformat, or, alternatively, don’t select anything, in which case reformatting will apply to the entire file. Then launch Reformat Code in one of three ways:
 

• Choose ReSharper | Code | Reformat Code on the main menu.
• Press Ctrl + Alt + F (no default shortcut in VS scheme).
• Choose Reformat Code in the context menu.

 

 
The Reformat Code dialog box (shown above) contains several formatting options:
 

• Optimize ‘using’ directives removes redundant namespace import directives from the source code. Note that this option is disabled when you have a selection – even if it includes the imports section of your file.
• Shorten references replaces fully qualified names with short names where possible by importing namespaces.
• Remove redundant ‘this.’ qualifier deletes unnecessary this keywords (note that it doesn’t do the same for VB.NET keyword Me).
• Reorder type members (for C# code only) reorders type members according to patterns specified in ReSharper Options | Languages | C# | Type Members Layout.

 
After you have reformatted your code, ReSharper saves the state of check-boxes for future use. Subsequently, you can even launch Reformat Code silently, without opening the dialog box, by pressing Ctrl + Shift + Alt + F (or Ctrl+E, F in the Visual Studio keyboard layout).
 
An additional advantage is that you can execute reformatting via Solution Explorer. For example, you can reformat a specific C# code file, or all such files in a project or entire solution. Just right-click the required node and choose Reformat Code….
 
Additional links:
 
Kyle Baley explains how to remove regions with the Reformat Code feature (C# only)
An example of how you can customize a type member layout pattern
Tips for using Reformat Code with aspx pages
Joe White’s detailed review of ReSharper’s reformatting tools

CamelHumps is a feature that identifies parts of compound names composed according to CamelCase, where each part starts with a capital letter (“hump”).
 
By default, it works in four navigation commands, namely Go To Type, Go To File, Go To File Member, and Go To Symbol, like this:

 
However, you should take an additional step to activate CamelHumps for the Extend/Shrink Selection (Ctrl + (Shift) + W, or Ctrl + Alt + Right/Left in the Visual Studio keyboard layout) and Next/Previous Word (Ctrl + Left/Right) navigation actions. To do that, choose ReSharper | Options | Environment | Editor and select Use CamelHumps.
 
From now on, CamelHumps is switched on, and jumping to next/previous word works in a slightly different manner. Specifically, when you press Ctrl + Left/Right, the caret moves to the next/previous uppercase character in the current word, and only after that, it moves on to the next/previous word.
 
Extend/Shrink Selection commands are also affected by CamelHumps. Suppose that the caret is in the middle of a compound word with several parts that begin with uppercase letters:

If CamelHumps is switched on, pressing Ctrl + W for the first time selects the current part of the word:

It’s only after pressing this keystroke for the second time that you can select the whole word:

All subsequent keystokes are processed as usual.
 
In addition, ReSharper provides four actions for using CamelHumps locally when the global option (Use CamelHumps) is switched off:
 

• ReSharper_HumpNext - move caret to next hump/word
• ReSharper_HumpPrev - move caret to previous hump/word
• ReSharper_HumpNextExtend - expand selection to next hump
• ReSharper_HumpPrevExtend - expand selection to previous hump

 
Of course, you can assign individual shortcuts to these actions in the Visual Studio Options dialog box (Tools | Options | Environment | Keyboard).
 
Note that both HumpNextExtend and HumpPrevExtend only work in a linear fashion, without additional functionality of Extend/Shrink Selection.

Note: This is the first post from a series that we’re hoping to maintain on a regular basis. Tagged as “ReSharper in Detail”, it will cover specific features provided by ReSharper with reasonable (or even redundant, for true ReSharper Jedis) details, links to other valuable web resources and probably some additional insight. You can think of it as extended online help for those users who feel not very comfortable learning or navigating through ReSharper functionality, as well as for those eager to gain additional expertise.

The Extend Selection feature allows you to successively select expanding blocks of code. You can easily select any expression in the code by clicking somewhere inside it and pressing Ctrl + W (or Ctrl+Alt+Right Arrow in the Visual Studio keyboard layout) a few times, or, alternatively, by choosing ReSharper | Code | Extend Selection.
 
To be specific, Extend Selection works the following way:
 

1. You place the caret at an arbitrary position – in this example, at a field name in a method call.
   
2. You press Ctrl + W for the first time.
    
   • If you selected Use CamelHumps in ReSharper | Options | Editor, the initial selection is made covering the current part of field name that begins with an uppercase character:
     
     It’s only after you’ve pressed Ctrl + W once more, the whole current word is selected.

    

   • If CamelHumps is disabled, ReSharper selects the complete field name straight away:
     
3. Press Ctrl + W again. ReSharper extends the selection to cover the field property:
   
4. The next time you hit the shortcut, the method name is added to the selection – without parentheses though:
   
5. Next expansion – parentheses are added:
   
6. We’re done with the method call expression. The next time you press Ctrl + W, the whole line is selected:
   
7. How the feature acts further depends on the structure of your code. In our example, the method call belongs to the body of a conditional statement. That’s why the next time you hit the shortcut, the whole body is selected, excluding braces:
    
   

 
In this example, consequent keystrokes extend the selection to cover the following:
 

• Body of the conditional statement including braces;
• The conditional statement including condition;
• Body of the method containing the conditional statement;
• The entire containing method;
• The class that this method belongs to;
• The entire file.

 
Obviously enough, Shrink Selection does exactly the opposite. Press Ctrl + Shift + W (or Ctrl+Alt+Left Arrow in the Visual Studio keyboard layout) or choose ReSharper | Code | Shrink Selection a number of times, and you can eventually find your selection cut down to the initial position of the caret in strictly reverse order.
 
This feature is very intuitive but please be aware that there are several scenarios where it should work on a limited basis or not work at all.
 

• ReSharper doesn’t process HTML and JavaScript. Because of that, Extend/Shrink Selection interprets any block of JavaScript or HTML code as an integral entity within a pair of tags and only discerns specific words within this block. In other words, when you’re working on an aspx file and you place the caret at a certain position within a JS or HTML block of code and you hit Ctrl + W, ReSharper selects the current word, and upon the next keystroke it selects the entire block of code within a pair of containing tags (for example, in case of JavaScript).

 

• You should start with extending a selection using Ctrl + W in order to be able to shrink it back later. In other words, if you made a random selection with your mouse or by clicking Ctrl + A, you can’t shrink it using Ctrl + Shift + W because in this case ReSharper doesn’t know exactly what file member you want to cut the selection to.

 

• Extend/Shrink Selection supports CamelHumps-based selections within both C# comments (//, ///, /**/) or VB.NET (‘) comments. However, commented code is not parsed and therefore interpreted as an integral entity (see note on JavaScript and HTML above).