Votes

Share

There used to be a options tab where you could enter functions that validate nulls. It was useful for registering the Assert.IsNull type functions that check for nulls before use of a reference. But it seems to be missing now. Sorry, not too much help.

value = null;if( !string.IsNullOrEmpty(value) ) // ReSharper shows a squggly under the expression: "Expression is always false" Console.WriteLine(value); // ReSharper DOES NOT show a blue squiggly under value.

value = null;if(!string.IsNullOrEmpty(value)) // ReSharper shows a squggly under the expression: "Expression is always false" Console.WriteLine(value); // ReSharper DOES NOT show a blue squiggly under value.

When you refactor this code, can I suggest having ReSharper analyze the deep logical tree (or full stack trace) instead of annotating? I think this would remove the need to annotate.

I don't know how this would affect performance, how recursive calls would work, or what would happen in other unclear or complex situations, but maybe this suggestion can apply in certain simple cases (like non-recursive non-virtual methods with a limited depth...).

Does this suggestion have any merit?

For example, if I have:

public bool IsNull(object value) { return value == null; }

and then a call:

if(!IsNull(someObject)) DoSomethingWith(someObject);

This translates logically to:

if(!(someObject == null)) DoSomethingWith(someObject);

(There's probably even a good chance this kind of call would be inlined in many cases.)

When you refactor this code, can I suggest having ReSharper analyzethe deep logical tree (or full stack trace) instead of annotating? Ithink this would remove the need to annotate.

I don't know how this would affect performance, how recursive callswould work, or what would happen in other unclear or complexsituations, but maybe this suggestion can apply in certain simplecases.

Our External Annotations (for the system DLLs) are the result of analyzing the deep logical tree, in fact. Written down, so that applying them takes some reasonable amount of time. We'll probably enable the same technique for source code in a future release. This way, methods that are clear about their nullity will get the annotations automatically.

In Resharper v3 there had been a list of methods and evaluations that would perform Null-Checks. They had been persisted in the resharper-file like this:<Configuration> <CodeInspection> <AssertionMethod MethodName="System.Diagnostics.Debug.Assert" Parameter="0" Type="IS_TRUE" /> </CodeInspection></Configuration>

I think I just figured it out by trying out the "copy default implementation to clipboard"-feature. This means I do not have to link to the JetBrains.Annotation assembly, which is preferable since we're building a framework and each external reference adds to the complexity of different projects using different versions of a third party component.

One question is left: What exactly is the purpose of the "default annotation namespace", i.e. can I use two annotation-implementations simultaneously?

You can use any number of annotation namespaces simultaneously, but when you ask ReSharper to put into code, it have to select one. This is exactly what "default namespace" is for. In other words, ReSharper listens to all namespaces, but speaks in default.

MK> Thanks Eugene!MK> MK> I think I just figured it out by trying out the "copy defaultMK> implementation to clipboard"-feature. This means I do not have toMK> link to the JetBrains.Annotation assembly, which is preferable sinceMK> we're building a framework and each external reference adds to theMK> complexity of different projects using different versions of a thirdMK> party component.MK> MK> One question is left: What exactly is the purpose of the "defaultMK> annotation namespace", i.e. can I use two annotation-implementationsMK> simultaneously?MK> MK> MichaelMK>

Another issue popped up. In nunit (and other testing frameworks, third party components) are a bunch up methods that do checking for a value being not null. Is it possible to annotate them as well like you did with the .net Framework (e.g. Debug.Assert (myValue != null) ) without editing the source code of those third party components?

Another issue popped up. In nunit (and other testing frameworks, third party components) are a bunch up methods that do checking for a value being not null. Is it possible to annotate them as well like you did with the .net Framework (e.g. Debug.Assert (myValue != null) ) without editing the source code of those third party components?

Java analog of CanBeNull/NotNull attributes could be used to add runtime checks that throw NPE in case null will be passed to NotNull annotated function parameter (http://blogs.jetbrains.com/yole/archives/000043.htm). Is it possible to add the same for ReSharper null-check attributes?

Java analog of CanBeNull/NotNull attributes could be used to add runtime checks that will throw NPE in case null will be passed to NotNull annotated function parameter (http://blogs.jetbrains.com/yole/archives/000043.html). Is it possible to add the same for ReSharper null-check annotations?