Resharper Isn't Always Smart

re: Resharper Isn't Always Smart

PeterRitchie — Tue, 01 Apr 2008 19:30:02 GMT

@Wayne: I ran VS 2008 Code Analysis.

But, there are some valid reasons for implementing the equality operator; it's not without consequences/work; but valid.

re: Resharper Isn't Always Smart

Wayne Bradney — Tue, 01 Apr 2008 18:37:05 GMT

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

re: Resharper Isn't Always Smart

PeterRitchie — Tue, 01 Apr 2008 14:12:41 GMT

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

re: Resharper Isn't Always Smart

David Nelson — Tue, 01 Apr 2008 13:59:16 GMT

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.

re: Resharper Isn't Always Smart

PeterRitchie — Tue, 01 Apr 2008 11:29:17 GMT

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

re: Resharper Isn't Always Smart

PeterRitchie — Tue, 01 Apr 2008 11:26:43 GMT

@Wayne: no complaints from Code Analysis about overloading operator==.

@David & Wayne: All ReferenceEquals does is cast (implicitly) and perform operator==.

re: Resharper Isn't Always Smart

Derik Whittaker — Tue, 01 Apr 2008 01:07:07 GMT

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

re: Resharper Isn't Always Smart

Wayne Bradney — Tue, 01 Apr 2008 00:40:37 GMT

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)

re: Resharper Isn't Always Smart

David Nelson — Mon, 31 Mar 2008 21:43:15 GMT

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.

re: Resharper Isn't Always Smart

Steve — Mon, 31 Mar 2008 21:17:48 GMT

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 ;)

A case where Resharper will break your code with a

DotNetKicks.com — Mon, 31 Mar 2008 18:45:02 GMT

You've been kicked (a good thing) - Trackback from DotNetKicks.com