.NET Tools
Essential productivity kit for .NET and game developers
Why is ReSharper suggesting this?
Regular feedback we hear from the ReSharper community is how helpful it has been in learning the latest features of .NET. ReSharper is the pair-programming buddy you’ve always wanted, helping you with hints, tips, warnings, and catching errors. While fixing issues is essential, understanding why a code change is positive is vital to a software developer’s growth.
We always provide you with as much information as possible to make the ultimate decision about your code, putting the power of choice in your hands.
In this post, you’ll get a quick recap of code inspections, what they are, and how to apply them. Additionally, we’ll see how to use ReSharper to help explain the reasoning behind any change.
Code Inspections and How To Fix Them
The ReSharper language engine provides developers like you with over 1500+ code analysis rules, 1900+ code-issue fixes, 58 solution-wide refactorings, and 470+ context actions. And thanks to ReSharper’s ability to provide context-aware recommendations, that amount doesn’t have to be overwhelming!
If you’re a long-time ReSharper user, you’re likely familiar with the lightbulb, a UI element that notifies you that an action is possible.
The context menu filters and orders items by actions, refactoring, and then inspections. Inspections help you write better code. Some are suggestions to make code more readable or to use a new C# language feature. Others are potential indicators of “code smell”, elements of code that might not technically be wrong but could add to you and your team’s technical debt over time. Code inspections might also be language-usage opportunities, typically present when upgrading a codebase from one version of .NET to the next. ReSharper can also indicate code inspection hints with “squiggles” under a code element.
You can think of code inspections as guard rails, helping you keep your code within a set of agreed-upon conventions. While some code inspections have straightforward fixes, such as the “Inconsistent Naming” inspection, some are a bit more obtuse. Code inspections typically have a set of matching actions that can fix the issue for you.
For example, the “Inconsistent Naming” inspection has a quick-fix Rename to, which will change a symbol to match your project’s code style.
If you feel a code inspection is incorrect, you can always use the sub-menu of a code inspection to modify your code inspection settings. For example, you can disable a code inspection one time with a comment, configure the severity, or apply different settings according to the inspection. Of course, these actions will vary by code inspection.
While the reasoning behind some code inspections may seem straightforward, others may leave you curiously scratching your head. Let’s take a look at one in the next section.
Learning More About Code Inspections
As you dive deeper into complex code usage, it’s easy to make mistakes that are difficult to spot but can have a devastating impact on your application. ReSharper helps catch these mistakes with code inspections, but sometimes there isn’t a clear-cut answer. In these instances, we can best educate you on why this may be an issue and whether you want to reconsider your approach.
Take the following example, where you can see a code inspection of “Inconsistent order of taken locks”.
By navigating through the sub-menu, you will see a menu item: “Why is ReSharper suggesting this?” Selecting that item will guide you to our official ReSharper documentation with the reasoning behind the code inspection and an explanation of the dangers of your current code.
In our sample of “Inconsistent order of taken locks”, the documentation states:
“If your class has multiple resources protected with locks to achieve thread safety, ReSharper analyzes possible execution paths in a multi-threaded environment (assuming the public API of the class can be used simultaneously by multiple threads) and the order of locks taken on such execution paths to find cycles leading to possible deadlocks at runtime, as illustrated in the example below. The warning message provides a detailed explanation and an example of a cycle that could be formed.”
ReSharper Documentation
Looking at our code and the sample provided in the documentation, we can see that ReSharper is correct, and now we understand the issue better.
namespace CSCodeAnalysis;
class Locks
{
private static readonly object Lock1 = new();
private static readonly object Lock2 = new();
public void SomeMethod1()
{
lock (Lock1)
{
// do things
lock (Lock2)
{
// do other things
}
}
}
public void SomeMethod2()
{
lock (Lock2)
{
// do things
SomeMethod3();
}
}
private void SomeMethod3()
{
lock (Lock1)
{
// do things
}
}
}
As you can see, the sample declares locks at the class instance level, and the code uses them across multiple methods, which the application could call in different threads. Deadlocks are bad. Thanks, ReSharper!
Summary
The ReSharper team of .NET experts has found a way to package their knowledge over the years into code inspections, giving you the world’s most brilliant pair-programming partner. While fixing issues in your code is important, we think it’s even more important to understand why you’re making those changes. The “Why is ReSharper suggesting this?” menu item gives you quick access to a knowledge-dense repository, allowing you to level up as a developer. Over time, you’ll learn and understand these issues, helping improve the world’s code one fix at a time.
We hope you enjoyed this post about ReSharper. Please comment below and share your favorite code inspection and reasoning why.
Image Credit: Jaredd Craig
Subscribe to a monthly digest curated from the .NET Tools blog:
