Resharper Isn’t Always Smart

I was writing some code today, essentially like this:

public class MyClass

{

    private int value;

    public MyClass(int value)

    {

        this.value = value;

    }

    public static bool operator==(MyClass left, MyClass right)

    {

        return left.value == right.value;

    }

 

    public static bool operator !=(MyClass left, MyClass right)

    {

        return !(left == right);

    }

}


    //…

    MyClass myClass1 = new MyClass(1);

    MyClass myClass2 = new MyClass(1);

    if((Object)myClass1 != (Object)myClass2) // “Type cast is reundant”

    {

        Console.WriteLine(“not equal”);

    }

    else

    {

        Console.WriteLine(“equal”);

    }

…where Resharper warned that both the casts to Object were redundant and offered a “Quick-fix” (red light bulb) to “Remove cast”.  Well, doing that to one of the casts results in a compile error so you have to manually change the other; but what it’s suggesting is this:

    if(myClass1 != myClass2)

This completely changes the output of my application from “not equal” to “equal”.  What Resharper doesn’t know (or doesn’t care to check) is that removing those casts switches from a reference comparison to a value comparison and may have different results.  What I wrote with the original code was to test if the two references referenced the same object.  The default behaviour of a class is to do a reference check; but I’ve overloaded operator== (and operator !=) to perform a value comparison (I’ve left out the lovely bits that truly gives MyClass value semantics for clarity).


So, when Resharper offers to change your code, be sure you know side-effects of that change before you let it do it.  You could introduce a nasty bug.


kick it on DotNetKicks.com

10 thoughts on “Resharper Isn’t Always Smart”

  1. Yup, had the same problem a few times, this one still compiles but some “fixes” even generate compile errors, but I always report problems like this.

    Anyways, ReferenceEquals is always usefull for this ;)

  2. This is exactly why I never use a cast to Object to perform a reference comparison: it is confusing to the reader, whether the reader is a human or a refactoring program. Instead I use ReferenceEquals; it immediately and clearly signifies what kind of comparison I am trying to accomplish.

  3. Isn’t this just the kind of thing that Object.ReferenceEquals() was invented for?

    (Also, Code Analysis does suggest that overriding == is a bad idea for most reference types)

  4. @Peter,

    Is this with 4 EAP?

    Well, to be fair. #R does not know that you changed the default meaning of the != operator.

    But your message is true, and it is not just when using #R. Anytime ANYTHING changes your code you need to know the intent of the change before you allow it.

  5. @Derik: Yes, 4 EAP. It could know. And if they don’t want to check, then don’t suggest the “quick-fix”.
    It’s the same with Code Analysis, don’t change the code simply to get rid of a warning, unless you know what you’re doing…

  6. I am well aware of how ReferenceEquals operates. I was not saying that it does something different; I was merely pointing out that it is more explicit about your intent and tends to be less confusing.

  7. @David: Depends on point of view, I guess. To me and all the developers I work with (Object)x==(Object)y is obvious to me.

    It is apparent that ReferenceEquals is more R#-friendly.

  8. Really? I get CA1046 right away when compiling your sample:

    Warning 5 CA1046 : Microsoft.Design : ‘MyClass’ should not overload the equality operator. C:\Users\wayne_bradney\Documents\Visual Studio 2008\Projects\ConsoleApplication7\ConsoleApplication7\Program.cs 7 ConsoleApplication7

Leave a Reply

Your email address will not be published. Required fields are marked *

You may use these HTML tags and attributes: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <strike> <strong>