From time to time, I install a trial of ReSharper. Because
colleagues and fellow developers all over the world praise this
tool as if it is pure magic. Now, in my case ReSharper's magic was
always to slow my Visual Studio down to a nearly unusable speed and
to crash it very regularly. Also, it flooded my IDE with wrong
error messages that you could only get rid off by restarting Visual
Studio. To me it seems that with ReSharper, you spent most of your
time waiting, restarting your IDE and praising this tool for some
Agreed, with new Dual- and Quardcore machines spreading through
our dev dungeons and surely some optimizations by JetBrains
Resharper got to a more usable speed level during the last years.
It is also more stable than ever, what does not mean much, though.
That's why I try to install it again from time to time, just to
check if things got better.
Now, while it indeed got speedier and more stable, ReShaprer is
more evil than ever: it's more intrusive, it's
scareware like many of the "security suites" out
there that frequently bombard you with warnings and "informations"
that should show you how important it is that you have this
software installed and how screwed you are if you don't use it.
Even worse, it very often makes catastrophic refactoring
recommendations that, unfortunately, many of the ReSharper users
out there gladly adopt without thinking about consequences because
they trust in a tool they really shouldn't trust in.
Of course I have examples for you. Because just after installing
ReShaprer, it flooded my project with hundreds of warnings like
every scareware would do to make itself important. "Gosh! I'm such
a bad programmer!" you might think when looking at the mess and you
will be glad that this tool will at least camouflage this by fixing
your bad code. No, trust me, you're a good programmer. ReSharper
just want you to believe you are bad and only ReShaprer can help
Now … why ReSharper is evil:
ReSharper is evil because it urges you to remove used code
Here you see a standard XAML file on a Windows Phone project.
ReSharper urges me to remove the ApplicationBar's from the XAML
because they aren't used. If I would do this now, my project will
build fine, but will crash like a flying penguin at runtime because
this XAML markup IS used. Not in the XAML, but in code behind:
ReSharper doesn't check this, but nevertheless urges you to
remove code. This is marked as a Warning by
ReSharper, so it's clear a developer coming by this will remove it
in good belief. That's catastrophic because this, in worst case, is
an error that might come up no earlier than in customer's hands as
it won't break your Build and it might be hidden deep inside your
You really want to trust a tool that comes up with such
horrible, bad checked recommendations?
ReSharper is evil because it will tell you that your perfectly
fine code is wrong
ReSharper thinks here is somewhere a redundant check. No there
isn't. It will just cost you time to think about an error where
there isn't any.
ReSharper is evil because it enforces inconsistent formatting
Just as ReSharper is evil, underscores in modern C# code are
evil. Or at least a relict, to be fair. So it's fine that ReSharper
wants you to remove underscores from event handler methods:
But then, ReShaprer wants you to use the saved underscores for
No, C# coding guidelines suggest to just use camelCase and no
ReSharper is evil because it forces you to castrate your fine
ReSharper thinks that the "var" keyword should be used instead
of a complete type name left-side of the declaration:
JetBrains sais that the use of the var-keyword is well-argued
here but: the left side is where you would normally look for the
type in this declaration. It makes your code more readable than to
have to search for the type on the initializer side. I understand
that you have to write a lot of extra-chars for this benefit and
using var on the left side would be easier. And that's
understandable … but there's no reason that you have to refactor it
later on if you have this already written like that. Don't make
code less readable than it was just because ReSharper makes you
believe that's better coding.
That's one of many examples where ReShaprer bombards you with
unnecessary recommendations just to make itself more important. It
would be OK if this recommendations were more subtle, but with all
those curly underlining of such unimportant "errors", ReSharper is
much too intrusive and distracts developers from really important
This is called advertising.
ReSharper is evil because it thinks it knows better what you
want to do than you
If you assign a value to your variable only in the constructor
of a class, ReSharper wants you to make this field read only.
Seriously, wtf? I know when I want a field to be readonly. I have
good reasons when I do that. And even if I don't use this field
currently anywhere else than in the constructor, I or someone else
might in the future. If it's not ok to write to this field I will
make it readonly.
It's just another example of the flood of self-advertising of
ReSharper. Same functionality more hidden or just on demand - ok,
why not. But offensive like that including curly underlining? Oh
So, finally …
… these are just the things that came to my eye in the first 15
minutes after I installed ReSharper. There will be a lot more and I
might add more examples in this post in the future. From
destructive code refactorings that kill your app to all those
unnecessary and over-prominent suggestions to change your code -
ReSharper remains a very problematic tool.
If you want to use all the (many) good features of ReSharper,
you will have to spend a lot of time in fine-tuning it and turning
off all the crap it does to advertise itself. Very often you also
have to disable good functionality to "fix" bad things ReSharper
does, like the suggested XAML removal above - it's useful that
ReSharper shows you code that is deprecated / unused - but you have
to turn it of because you can't trust it.
If you use ReSharper anyhow, use it wisely and don't put
ReSharper over your own coding skills. While it is very helpful,
not to say essential, in many on-demand refactoring
scenarios, most of the "live" checks should be used with extreme
caution or even turned off. For coding and styling guidelines
better go with tools like FXCop.
Update 1: Even more examples
ReSharper tells me about a possible null reference exception
where I just checked just for that one line earlier. Unnecessary
curly lines everywhere distracting me from more important things.
Also, the only way to get rid of this curly underlining in this
case is to make the LINQ query more complicated and unreadable or
to disable null reference checks in general.