How does ReSharper know something is always true/false?

I am new to ReSharper and I have noticed it says a lot of our bool tests for null are always true or false when in fact they are not.  I thought that odd, because we usually test for this, and only put them in when we know for a fact an object can be null or we had a NullReferenceException at some point and added to fix a bug.

So I dug into several of them, and sure enough every single one of suggestion by ReSharper is wrong here.  I can look at the code and follow it through and see where it can be set to null, and that nulls are being set intentionally as a way to check for something.

I understand how it can set for this within its current immediate scope, however once you start calling other methods how can it be figuring out if a method that is being called will never return a null object and therefor make the check unneeded?  This is really annoying that it sees this at just about every null check in our code, and before I disable it I want to know what is up.

3 comments
Comment actions Permalink

Hello Rodney
     Could you please add some sample code demonstrating the case where ReSharper analysis is wrong? Thank you!

Andrey Serebryansky

Support Engineer

JetBrains, Inc

http://www.jetbrains.com

"Develop with pleasure!"
0
Comment actions Permalink

I don't know just about any code you can write with a bool test that isn't a simple all done in the same scope of the test.  For example:

bool isValid = false;

isValid = (2 + 2) == 4;

if (isValid) Console.WriteLine("This Works Well");

However if you have a bool that is determined by the results of a method call, then ReSharper seems to always say the bool will always be true usually (sometimes false) and is not needed.  However if you dig into the method that is called it actually can be true or false, depending on the outcome.  It does this even on 3rd party libraries calls that return bool sometimes.  Usually though it is on internal code that ReSharper would have access to explore.

Also noticed it does this with null, saying that something can never be null when in fact it can be.  I am not sure how these two algorithms you have figure this two items out, but they don't work, and I am not sure how they can reliably unless they are following the whole path of the code and are some how able to tell with 100% accuracy that this is the case.  

I can't share our code, and I don't have time to work out a sample project.  I just disabled  all your suggestion for now as I can't trust them and so its better they are off.  I only an evaluating the product for the Refactoring functionality anyways so not worried if I have to disable all the other features.  

0
Comment actions Permalink

Please could you provide sample code where ReSharper' analysis is wrong.
Thank you in advance

0

Please sign in to leave a comment.