What happened to 'Value Analysis'

Hi there,

in the 4.0 EAP, what happened to the configuration screens for 'Highlighting - Value Analysis'?

I'm running the first EAP, 4.0.730.31, and I'm getting an error flagged ("Local variable XYZ might not be initialized before accessing") because it doesn't realise my own Fail() method throws an exception.

I used to be able to configure that, in (I think) Highlighting - Value Analysis. But I can't find that in the ReSharper configuration any more. Am I looking in the right place? Or is it just not there any more?

Cheers,

Geoff

35 comments
Comment actions Permalink


> Since these attributes are essentially ignored outside of RS (or custom test code that understands them), I don't see your point, or any benefit to a mechanism that does not embed these annotations for reuse by all.


The main benefit is that if the mechanism doesn't require changing the code, it will be possible to use it. If the mechanism requires changing the code, it will not be possible to use it.

I understand what you're saying about annotations, but so far nothing except ReSharper understands them and there's no guarantee that anything else ever will. And while I can see what you mean with custom test code, I don't think that's necessarily applicable. What I mean is, take the following code snippet:

public string DoSomething (object param1, string param2)
{
PreCondition.NotNull(param1);
PreCondition.NotNullOrEmpty(param2);

// Actually do some work

PostCondition.NotNullOrEmpty(result);
return result;
}

What benefit do attributes with custom test code bring here? Surely the custom test code should be looking at the use of the methods to dictate the contract - using attributes to specify the contract for a method is duplication just for the benefit of ReSharper - and duplication that's likely to get out of sync with the code at some point.

Without bringing in a whole attribute-based AOP system, I don't think using attributes will provide any of the benefits you're thinking of in the short to medium term. (And in the longer term, who really knows?)

Geoff

0
Comment actions Permalink

In my case, I started using attribute annotations before using RS, so I already have custom code that knows what to do with them. As a simple example, even though a parameter is decorated "NotNull", that still does not prevent a null being passed in -- it just causes RS, if used, to watch for these occurrences. Since RS is always optional, and not yet integrated into any source control system "check in" policy (that I know of), it is still prudent to have the code check for a null and throw the appropriate exception (similar to your use of Precondition...). It is even more prudent to have a test that passes in null, to ensure that the code itself performs the check. The ability to automatically generate tests for semantics of known attributes (NotNull, which RS has, NotNullOrEmpty,which RS does not yet have, ranges, ...) goes a long way. For example, it would detect cases where methods/properties disagree on support for null (either by throwing an exception even though not decorated as NotNull, or by not throwing the correct exception if decorated as NotNull).

So personally I wanted RS to support allowing me to state the name of my existing attributes, rather than have to rearrange things to work with the final RS mechanism. However, it was no big deal for me to adopt the RS mechanism.

Sadly, C# (up to and including 3.0) was not designed with code correctness as a strongly motivating factor. Hence no embedded support for tight semantics specifications. If you are interested in something from MS along these lines, check out Spec# ( http://research.microsoft.com/SpecSharp/ ).

Your internal use of Precondition... and Postcondition... are a good approach, but they do not automatically document (i.e. educate) the caller as to the semantics of the code. This is not necessarily a roadblock to test generation, as tools like Pex ( http://research.microsoft.com/Pex/ ) from Microsoft Research dynamically execute the code, and will generate test cases to trigger all your semantic checks. There is also support for Pex in many of the major test frameworks ( http://www.codeplex.com/Pex ).

However, a mechanism that supports making these semantics automatically included in Intellisense, Sandcastle, or other code documentation tools is much preferred, and that is where code attributes are preferable over just embedding dynamic code checks.

In your case, given the existence of Precondition... and Postcondition..., I would think it a small matter to include the RS annotation source code in the same code-semantic-issues namespace as the *condiion classes.

0
Comment actions Permalink

Slightly off-topic, but... For those interested in Pex, remember that its license only permits its use in education and "personal research" situations. It is (sadly) a violation of the license to use it in a commercial setting. :(

0
Comment actions Permalink

Sadly, the same applies to Spec# -- non-commercial use also. However, if Microsoft can be encouraged to turn these into products, we would all benefit.

Until then, the concepts can still be explored to a significant degree without violating the license(s).

0
Comment actions Permalink

3. This works for all of ReSharper except for the value analysis. To get
that to work, I must change the core project code to introduce
attributes that provide no benefits to the customer or company - only for
the few developers on the team that use ReSharper.


You could consider it a benefit to the customer and company if it helps you
find a bug before it makes it to production.

---
Richard


0

Please sign in to leave a comment.