Why ReSharper is evil

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 sadomasochistic reason.

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 you out.

Now … why ReSharper is evil:

ReSharper is evil because it urges you to remove used code

image

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:

image

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 application.

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

image

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 guidelines

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:

image

But then, ReShaprer wants you to use the saved underscores for instance fields:

image

No, C# coding guidelines suggest to just use camelCase and no Hungarian-like notations.

ReSharper is evil because it forces you to castrate your fine self-describing code

ReSharper thinks that the "var" keyword should be used instead of a complete type name left-side of the declaration:

image

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 things.

This is called advertising.

ReSharper is evil because it thinks it knows better what you want to do than you

image

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 my.

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

image

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. Don't like.

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.

12 comments for “Why ReSharper is evil”

  1. Posted Thursday, February 9, 2012 at 10:18:07 AM

    Hi Bernhard,

    Thanks for your detailed feedback. Just would like to follow up on a couple of topics:

    - Resource not found: I'd like to be able to reproduce this so if you could please submit an issue to http://youtrack.jetbrains.net/issues/RSRP that would be great.

    - Redundant check: Could you please tell me in which cases you feel there is an error. I've not been able to encounter one despite covering all potential cases.

    - Naming guidelines. Naming in ReSharper is completely configurable and is a one-off thing. In fact you can now even configure it once across multiple projects, teams and entire organization. Obviously people have different styles when it comes to naming. We provide a default which is very easily configurable. I wouldn't go as far as to say that is evil.

    - Usage of var. Again, this is a matter of personal preference that can easily be switched off. I've already commented sufficiently on var in the past to repeat myself here, but you can find some of my thoughts at: http://devlicio.us/blogs/hadi_hariri/archive/2009/11/20/var-improves-readability.aspx

    - Readonly. This is a suggestion which actually falls in line with good practices such as somehow forcing Dependency Injection and favouring loosely coupled code. Again, sufficient has been written about this on the Internet for me to add anything else. Please Google for topics such as SOLID and Dependency Injection. And again, this is optional. You can turn it off easily much like many of the other things you point out as evil.

    Regarding last example per Twitter could you send me a code snippet of what you mention it converts it to?

    Thanks.


    -

  2. Posted Thursday, February 9, 2012 at 1:50:10 PM

    Hi Hadi,

    thanks for your response.

    - Resource not used: I try to extract the code to a small sample project to send it to you asap.

    - Redundant: what I'm doing is just to check if the value has changed before assigning a (new) value to the UI element. I really don't see how this could be a redundant check. I could have written the comparsion a bit easier (.IsEnabled == syncState) but it doesn't change ReSharpers opinion that this is a redundant check.

    - All other points:

    I don't think ReSharper should not offer this refactoring possibilities. Sure it is often a matter of taste ... and to have ReSharper help you adapting your code to your personal taste in a fast and automatic way is great. My problem, as explained above, is that this is propagated to offensive and often with the not ideal default settings (IMHO), the var topic for example is really too controversial IMHO to make it default. I fully understand your argument there, but I don't think it's good that ReSharper is that offensive with these change recommendations.

    My experience is that developers tend to blindly follow ReSharpers default suggestions without really thinking about it. Yes, that's also a fault by the developers, but when ReSharper does curly underlining everywhere and make changes look more important than they are, I can't blame it only to them. If many of those suggestions would not be that offensive, I won't have a problem with it. But the way ReSharper "promotes" these features, I indeet think it's evil, even if I know I intentionally exaggerate with this word ;)

  3. Posted Friday, February 10, 2012 at 8:10:05 AM

    Bernhard,

    The check is redundant because independently of the input values, the end result will always be the same. Try it out. Take different input values and see the outcome. As such, that conditional adds absolutely no value. Why it doesn't add value is because of the way you've written the conditional statement.

    All other points, in ReSharper we now have an option to explain Why we think this is a good idea. We need to set some defaults. No matter what we choose, someone won't like it. Many people hate regions and love var's and like that ReSharper recommends var by default. I understand it's a matter of taste, but I think it's important to distinguish between what is evil and what is preference. And I'd say that the issues you outline are not evil per se.

  4. Posted Friday, February 10, 2012 at 2:10:12 PM

    Hadi,

    thanks again for your response. Maybe I understand something wrong but the outcome IS different:

    * Possibility 1:

    IsEnabled = True; SyncState = True;

    As in the condition, SyncState has a negation operator, this gets translated to:

    IsEnabled = True; SyncState = False;

    The != condition will result in TRUE.

    * Possibility 2:

    IsEnabled = True; SyncState = False;

    As in the condition, SyncState has a negation operator, this gets translated to:

    IsEnabled = True; SyncState = True;

    The != condition will result in FALSE.

    The outcome is: in possibility one, the IsEnabled property setter WILL be called, in possibility two the property setter WON'T be called. So the check is absolutely valid to prevent unneccesary calls to the setter of property IsEnabled.

    And again, my issue with ReSharper is mainly its offensive way to propagate this changes. The examples considered in isolation aren't all evil (besides for example the 1st example where needed code gets removed) but the whole concept of Resharper: it really should not force developers to do all this changes by massive curly underlining. Developers start changing their code just to get curly underlines removed.

    The var example is a good one here: just because ReSharper changes this:

    DataSet data = GetData();

    To this:

    var data = GetData();

    ... the developer doesn't rename data to something more meaningful. The developer does not apply this change because he knows why, but because ReSharper tells him that this is the better code. The result is bad, unreadable code.

    Only if the developer wants to change this because of his own intention, ReSharper should help him to do that, but not with curly underlines that suggest him he did something wrong.

  5. Posted Saturday, February 11, 2012 at 7:08:50 AM

    Berhanrd,

    Take the binary input values. Calculate the result of isEnabled for every single combination. Now remove the conditional and calculate isEnabled for every single combination. You will see that both lead to exactly the same result. That is why it's redundant whether or not you have that check.

    ReSharpers offers suggestions. In 6.0 you can now even ask Why in every quick action before applying a quickfix. If developers blindly apply things, then there's little we can do, even if IMHO those suggestions are correct.

  6. Posted Sunday, February 12, 2012 at 2:50:21 AM

    Hadi,

    yes I understand that the result for the value of IsEnabled is always the same. But IsEnabled is a property that has a setter. And in a setter there can be a lot of code that gets executed when a value gets assigned, mainly if this is a property belonging to UI controls. So while the value of IsEnabled will always be the same at the end no matter if I do my conditional checks before, there is a difference in the amount of code that gets executed during this process. So it's a valid approach to check if I need to assign this value no matter if the outcome of the VALUE for this property will always be the same. Of course, inside the setter, there should also be mechanisms to prevent unneccesary code to be executed if the value reamins unchanged, but UI controls are often blackboxes and you cannot know - so in performance-critic applications like a mobile app, I rather check for myself before calling setters of properties that might execute more code than needed.

    That's why I think that it's not good resharper recommends to remove this check. If some code isn't executed in certain conditions, it's valid to have those checks there. The final value of a property is not always the only thing that counts ;)

    As for ReSharpers suggestions - I won't blame it only to the developers as I mentioned earlier. ReSharper does a lot to push them in some directions, curly underlining screams "error". The theory that devs only take ReSharpers suggestions if they know exactly why ReSharper does suggest this is unfortunately only a theory. Even some devs I know that do question ReSharpes recommendations sometimes rewrite their (fine) code just to get rid of curly lines in their code. It was, in this case, the thing with the (wrong) null reference warning from my example above. The result was more unreadable code, but without curly underlining.

    It's good that ReSharper now offers to show infos about why a change is recommended, but it's still incomplete: for example, the change to var when i do something like DataSet data = GetData(); does not have an explanation and also not when ReSharper recommends to use var in a foreach statement. So devs just convert it because they think that if ReSharper recommends it, it must be the right thing to do.

    No offense, I find a lot to like in ReSharper and of course I see your points and understand your position. But I think ReShaprer should be a tool that needs to get out of the developer's way as good as it can. It should supplement the development work, but not dictate it. Too much features too offensivly promoted to the user. And unfortunately also sometimes buggy and problematic.

    I know the dilemma: this is also why most people love ReSharper :)

  7. Gravatar of Cameron ElliotCameron Elliot
    Posted Thursday, August 9, 2012 at 10:06:49 AM

    Seems to me you're blaming the tool because you don't know how to use it properly. You can configure R# to do as much or as little as you like, and it is extremely simple to change what it does.

    Nearly everything you've mentioned is configurable. Spend 10 minutes configuring R# it so it matches *your* preferences, and your every whinge will disappear!

    Oh and get an overclocked Core i7 with 16GB RAM like me :). Actually maybe the overclocking is overkill, but I like a snappy machine, and I find R# solution-wide analysis really handy. Compiling just to find compilation errors is *so* two years ago!

  8. Posted Saturday, August 18, 2012 at 11:37:00 PM

    Hi Cameron,

    some of the things I mentioned have nothing to do with configuration: for example the recommendation to remove unused XAML while it was indeed used. ReSharper goes very often far beyond what it should do just for that additonal curly underlined code for self-advertising. It's sometimes like scareware, and just as harmful.

    Configuration on the other hand is ok for a single developer, but when working in Teams, you are dependant on what other Devs do with this tool.

    And this is a main criticism - for many, ReSharper goes over own experience and own opinions and own knowledge.

    And just as an additional note: Compiling to find compilation Errors is something that was needed in C# 1.0 days but not today. VS does this Job just fine. And ReSharper does not. I cannot count the amount of times ReSharper threw wrong Errors at me that were gone after a VS restart. VS is the much more reliable tool for that, it never showed me a wrong or unneccesary error since years.

  9. Gravatar of Cameron ElliotCameron Elliot
    Posted Wednesday, August 22, 2012 at 9:05:30 AM

    Hi Bernhard,

    I also found the xaml support was a little suspect, so I used changed the Code Inspection settings and told it to skip "*.xaml", so no worries there any more. I might try it again in the latest version to see if it has improved, but don't have any great hopes.

    I think it's a little much calling it scareware or self-adverstising. It's just a tool which works within VS to show you things which *may* be wrong with your code. Of course it ships with a default configuration which unfortunately you may not personally agree with (I know I don't), but nobody at R# is trying to scare you. Is VS trying to scare you or advertise itself by showing compilation warnings?

    "ReSharper goes over own experience and own opinions and own knowledge." - I always thought having your own opinions and knowledge challenged was a good thing. Especially here where you can consider the challenge and within 5 seconds either agree with a suggestion and change your code, or disagree and turn the feature off. Hey and in teams you can share the same configuration, either that or everyone can just use their own coding standards and all produce wildly different code, but then they can do that without R# too.

    I must be a little rusty with VS because I have no idea how to make it show me all compilation errors in the entire solution without compiling, or take me to the next error anywhere in the solution at the click of a (key-mapped) mouse button. VS kind of *sometimes* updates the Error List as you type, but can only really be relied upon when you do a compile.

    I'm sorry you had such a bad experience with R#, I've no idea what could have led us to have such different experiences with it.

  10. Posted Thursday, September 6, 2012 at 5:55:37 PM

    Hi Cameron,

    Scareware is meant in the way that a software shows you (unneccesary) errors and warnings that make it seem ultimately necessary or else you're producing wrong code.

    I won't have a problem if ReSharper would show many of the "errors" more subtle, like other similar tools like Telerik's "JustCode" do. But ReSharper is very offensive and very intrusive in showing really unimportant "suggestions".

    It's easy to say that developers should know what they are doing - but the truth is that most of them, and of course I include myself, are far away from a level of 100 % understanding their language and framework. Not even to talk about devs that often switch their language and framework from project to project.

    They gladly adopt ReShaprers suggestions as there is a such great believe in this tool and because ReSharper is that offensive with its recommendations.

    This is even more the case since the pressure in this indurstry and it's easier to trust a tool to fix code than to use the time and learn the technology you use deeply.

    I can still remember the Visual Studio 4, 5, 6 times when I was a fan of IntelliSense and defended it against many people who said that features like IntelliSense prevent Developers from really learning writing code for themselves and makes them don't think much about what they writing as they trust the tools when something's going wrong.

    I disagreed with that a lot, but with ReSharper, this assistance is finally out of control IMHO. It goes much to far and Developers rely much too much on those tools and they get lazy because they know a tool is checking what they are doing in the background.

    I can only say again that in general, ReSharper is a product I WANT to use because it actually has a lot of great refactoring features. I mentioned Telerik's JustCode before and I like this a lot, but it's nowhere near ReSharper's featureset currently and it's not improving very fast.

    But overall, ReSharper has too many bugs, is too intrusive as explained before and not reliable enough by far.

    As an additional note: ReShaprer disables Visual Studio's own real-time error checking and error underlining. When you disable ReSharper, you migt get the impression that VS needs a compile before it shows errors because of this. You can re-enable these two settings in the language settings for C#. And again, I think VS does a much better and more reliable job in error detection than R#.

    I fully understand why people like R# and yes, I like it to for much of it features, but unfortunately, it goes far beyond what it should do and I don't think a developer does itself any good by using it.

    Cheers & thanks for your comments, it's an interesting discussion ;)

    Bernhard

  11. Gravatar of AdamsAdams
    Posted Friday, January 25, 2013 at 11:59:54 PM

    I use R#, but I have a really strong love/hate relationship with it. First off, part of setting it up for me is disabling about 2/3 of what it does. It's intellisence is awful. It's code autocomplete is dead slow, but even with this disabled it noticeably bogs down Visual Studio. The worst thing though is that half of its recommendations are not just wrong, they make for bad/inferior coding. It's approved code is harder and gives no real performance improvement - it's just somebody's opinion. R#'s refactoring tools are also slow and cumbersome, I can find my way around much faster in vanilla Visual Studio.

    Where Resharper shines is in its ability to clean up unused junk, and point out typos/sloppy mistakes while you're writing. These are far from critical though - you'll hit them as soon as you try to compile or run for the first time, so all it does is save you a minute here and there. I use R# to prune out dead wood - it's pretty useless at anything more.

    The idea that R# helps you write "better code" is the sort of thing that might fly for newbie or sloppy coders, but if you've got half a brain and a idea of how to design, you're right for finding that R# is a nuisance that gets in the way. Use it for what it's good for, and gag the rest with extreme prejudice, because it's a vastly overrated product written by a bunch of blowhards.

  12. Gravatar of Bernhard KönigBernhard König
    Posted Saturday, February 2, 2013 at 12:43:28 AM

    Hi Adams,

    what you're writing is pretty much that what I think of ReSharper too. And as I'd written, I also have kind of an love-hate-releationship with it as it does have many Features I want to use (like finding unused junk as you).

    But I disagree that this feature isn't possibly critical ... as I showed in the first example of my post, R# would remove used XAML code and this is something that won't pop up on compile time and not even on runtime. In this case, the problem could come up already in customer's hands. So take care when removing unused junk - it might not be as unused as R# makes you think it is ;)

Post a comment