ReSharper annoyances

By Jim, on February 26th, 2014

If you’re writing C# code, you should be using ReSharper. It’s a Visual Studio plugin that examines your code in real time (as you edit), helping you avoid common errors and write better code. I admit that I found ReSharper annoying when I first started using it, but after a week or so I found it invaluable. I found it so useful at work that I purchased a license myself so that I can use it at home. It’s not exactly cheap (about $150), but I find that it improves my code and saves me time. Well worth the price.

But sometimes its suggestions are just annoying. One in particular drives me bonkers. Consider this fragment from my heap selection code:

while (srcEnumerator.MoveNext())
{
if (ExtractCompare(srcEnumerator.Current, _numItems, _numItems, 0) > 0)
{
// The current item is larger than the smallest item.
// So move the current item to the root and sift down.
Swap(0, _numItems);
SiftDown(0);
}
}

ReSharper suggests that I “Invert ‘if’ statement to reduce nesting.” If I tell it to perform the transformation, it turns the code into this:

while (srcEnumerator.MoveNext())
{
if (ExtractCompare(srcEnumerator.Current, _numItems, _numItems, 0) <= 0) continue;
// The current item is larger than the smallest item.
// So move the current item to the root and sift down.
Swap(0, _numItems);
SiftDown(0);
}

So rather than having a simple conditional and a short bit of subordinate code, it inverts the conditional and adds an extra logical branch in the flow. All for no good reason. Rather than saying “If condition do x,” the code is now saying “If not condition go on to the next iteration, otherwise do x.” Negative logic and a more complicated control flow does not, in my opinion, constitute an improvement.

ReSharper is suggesting that I make my code harder to read and harder to understand.

Ostensibly, ReSharper is helping to avoid the arrow anti-pattern, but it’s being too aggressive. I fully agree that one should avoid writing such hideous code. However, the arrow anti pattern involves “excessive nested conditional operators.” One conditional operator is not nested. What we have here is a simple conditional that ReSharper should ignore.

I can change ReSharper options to disable that suggestion, or I could annotate my code to disable that suggestion in this particular case. I won’t do the former because I want ReSharper to suggest improvements that make sense, and I definitely want to avoid the arrow anti-pattern. I won’t add ReSharper-specific (or any other tool-specific) annotations to my code because those annotations are not germane to the problem being solved. They’re just clutter. It’s bad enough that I have to suffer those XML documentation comments in the code.

ReSharper got that one wrong, and there’s nothing I can reasonably do to prevent it from displaying the warning.

ReSharper also warns me when I write something like this:

private int _head = 0;

It says, “Initializing field by default value is redundant.” And ReSharper is right. But the redundancy is harmless and even helpful at times. I like this particular redundancy because it explicitly states what the initial value of that variable is. I don’t have to think, “Oh, right. The default value is zero.” I’ve turned this warning off because there is no context in which I want to be told that my preference for explicit initialization is redundant. Besides, the compiler will silently remove the redundancy, so there’s no inefficiency in the generated code.

Come to think of it, I’d like an option to flag code that doesn’t explicitly initialize something. I’d enable that option in a heartbeat.

All that said, I really like ReSharper. As annoying as it can be from time to time, I find that it really does help me write better code. Highly recommended.

2 comments to ReSharper annoyances

Actually, this “Initializing field by default value is redundant.” can make sense. I looked it up the other day, and it seems to be a performance hit (10-20% on first initialisation lateron, you can just search the issue at stackoverflow), if you declare stuff to early and or without good reason.
I suppose you will set the value anyways lateron, so try to live with the implied default values null and 0 whereever its possible. (Eventhough I personally think its more readable)

But i found another thing with resharper. so be careful with it, look at the code (Form1 Solution) and resolve a few issues, ylu will see it yourself:

using System;
using System.Collections.Generic;
using System.Diagnostics;
using System.Globalization;
using System.Windows.Forms;

I’d be pretty surprised to see any performance hit from that default initialization redundancy. If the C# compiler doesn’t remove it as redundant, I’d fully expect the JIT compiler to do so. It’s a trivial transformation. Considering the other optimizations that the compilers perform, it wouldn’t make sense for them to ignore this one. Furthermore, that single assignment is not enough to make for a “10-20%” performance hit in the initialization of a class. Not unless the class is nothing more than a bunch of variables.

I’d like to see where you got your information. Do you have a reference?