JetBrains .NET Tools Blog

Over the years, ReSharper has gradually advanced from plainly highlighting errors and problems in individual code files to somehow summing up errors and problems in a larger scope, up to the entire solution.

Back in 2007, ReSharper 3.1 was the first product version to introduce Solution-Wide Error Analysis to gather data on all errors in the solution using a single tool window. ReSharper 4.5 split many code inspections to execute in private and public scope, with the latter only available when you turned on Solution-Wide Error Analysis.

Taking another huge step towards instantly seeing every problem anywhere in your solution, ReSharper 5 introduces a new code analysis feature called Solution-Wide Warnings and Suggestions. As you’ve probably guessed, it lists all warnings and suggestions that ReSharper displays in the scope of your whole solution or in a narrower scope, depending on how you call it. In other words, any code smells or other problems that you may have in your solution can now be summarized in a single tool window, making tool-based code review much easier.

When you switch on Solution-Wide Errors Analysis, Solution-Wide Warnings and Suggestions starts showing errors as well, plus warnings and suggestions that work in non-private scope.

That doesn’t mean Errors in Solution tool window becomes obsolete with R# 5: when your goal is as simple as to make your code compile, Errors in Solution quickly indicates that something in the solution went awfully wrong and you should fix things up before you can compile.

However, as soon as you’re ambitious enough to make your code green - that is, eliminate compiler warnings, implement best practices, or upgrade your code to leverage the latest language opportunities - Solution-Wide Warnings and Suggestions is exactly what you need to get the job done quickly.

The feature includes two items:

• Inspect Code - a new command that is available by right-clicking any node in Solution Explorer, from a single file to the whole solution:
  
• Inspection Results - a tool window that actually shows problems found in a certain scope, broken up into several categories:
  

The Inspection Results tool window is pretty much similar to other ReSharper tool windows like Type Hierarchy or Find Results: it provides common navigation, grouping and export options. It also has a code preview pane where you can instantly see the context of a problem without opening the corresponding file in the text editor:

The tool window is not updated automatically, so as soon as you’ve made substantial changes, make sure to click the Refresh button to see up-to-date inspection results:

In many scenarios, chances are you don’t want to review all code problems you may have in a scope - you’d rather focus on a particular subset. Inspection Results lets you do this by clicking the glaring Filter button:

This displays the Filter Issues dialog box where you can select or unselect individual inspections or even entire inspection groups. For example, here’s how you can discover code that can be transformed to leverage C# 3.0 and C# 4.0 language features:

When you double-click an item in Inspection Results, the corresponding file opens in the text editor in the right position for you to actually take measures: apply a quick-fix, refactor or clean up code, or whatever:

However, instead of double-clicking through all inspections, in many cases you can apply fixes right from Inspection Results: say, you’re inspecting a single file that has three inspection items:

Of the three inspection items, two can be safely fixed using Code Cleanup, which can both delete a redundant “using” directive and make an explicitly typed variable implicitly typed. Then, you press Ctrl+Alt+F right on one of these two inspection items, and the Code Cleanup dialog box displays:

You launch Code Cleanup with Full Cleanup profile, and ReSharper applies fixes for both inspections straight away! Upon refreshing Inspection Results, you only have one inspection left:

In addition to cleaning up code, you can also apply refactorings and navigation actions right from Inspection Results. I hope to cover scenarios involving this approach in subsequent posts about ReSharper 5.

To try out Solution-Wide Warnings and Inspections in its latest incarnation, make sure to download a fresh ReSharper 5 nightly build!

On the eve of ReSharper 5.0 going beta, we thought it’s just about time to start elaborating on new R# features. We’re hoping for a series of posts on improved code analysis, navigation to and within external sources, structural search & replace, ASP.NET support, and other stunning capabilities that ReSharper 5.0 provides. Today, we’ll talk about R# going crazy over LINQ.

Among many new code inspections introduced in ReSharper 5.0, two are specifically aimed at converting for and foreach loops into LINQ statements and/or combinations of extension methods and lambda expressions. Here they are:

• Loop can be converted into LINQ-expression
• Part of loop’s body can be converted into LINQ-expression

If you are wondering why you would ever transform traditional cozy loops to LINQ, Jimmy Bogard, Matthew Podwysocki, and Justin Etheredge have done a great job of explaining why.

Back to ReSharper work, let’s see how it converts loops to LINQ method or query syntax for you in common scenarios.

First, there’s the aggregation scenario where we loop through a collection in order to get the number of this collection’s items for which a certain condition holds true:

ReSharper highlights the foreach keyword with a green curly underline. You press Alt+Enter for available actions, and ReSharper suggests that you convert the loop to a LINQ expression:

You apply the conversion, and here we go: no more temporary counter variable. Instead, we’ve got Count extension method with a lambda-styled condition:

Next, we’re taking on the transformation scenario where we’re looping though a collection to populate another collection:

Again, ReSharper is smart enough to see that the code fragment can be converted to LINQ method syntax:

On the output side, we’ve got one line of code instead of three, thanks to the ToDictionary extension method:

For the next scenario, let’s take a collection and filter it out, so to speak, like this:

ReSharper encounters three foreach loops and readily suggests that we convert each of them. Because conversion only occurs within a selected loop and its nested loops, let’s press Alt+Enter at the top-level loop:

What we’ve got here is a pretty return statement that leverages LINQ query syntax:

All three examples above show how ReSharper converts entire loops to LINQ. In many cases, specifically with write usages inside loops, that can’t be done. For such occasions, ReSharper provides its second LINQ-related inspection: Part of loop’s body can be converted into LINQ-expression. Unlike the previous action, it’s displayed as a hint and highlighted with a straight green underline.

Let’s take another foreach loop with a complex condition and a write usage inside:

Pressing Alt+Enter at the foreach keyword highlighted as a hint lets you convert a part of the loop to LINQ syntax:

ReSharper integrates the condition with iteration variable definition, resulting in a LINQ query that makes the previously bloated write usage clear:

If, for any reason, you want to keep your loops for future generations and you don’t need LINQ-related code inspections, or, say, you want them to display as warnings or even errors, you can always configure them by choosing ReSharper | Options | Code Inspection | Severity.

The two loop 2 LINQ inspections and many more exciting features are available right now: we keep publishing fresh ReSharper 5 nightly builds that you can download and evaluate.