Suppress "Member is never assigned to" warning in C#

Question

I have the following code:

ViewPortViewModel _Trochoid;
public ViewPortViewModel Trochoid
{
    get { return _Trochoid; }
    set { this.RaiseAndSetIfChanged(value); }
}

using ReactiveUI INPC support. The compiler is always warning me that Trochoid is never assigned to and will always be null. However due to the magic that RaiseAndSetIfChanged performs through CallerMemberName support, the code does work and the compiler is wrong.

How do I cleanly suppress these warnings in my code?

score 15 · Accepted Answer · answered Feb 08 '13 at 08:33

15

How to cleanly suppress these warnings in my code

An alternative to an inappropriate assignment would be to just a #pragma:

#pragma warning disable 0649 // Assigned by reflection
ViewPortViewModel _Trochoid;
#pragma warning restore 0649

That should work, and it keeps the ugliness at exactly the place that it makes sense to document it - at the field declaration.

If you have multiple fields handled in the same way, you could put them all in the same "block" of disabled warnings, with a comment applicable to all of them.

Whether you view this as "clean" or not is a matter of taste, of course. I think I prefer it to assignments which are only there for the side-effect of removing the warnings.

answered Feb 08 '13 at 08:33

Jon Skeet

1,421,763
867
9,128
9,194

Though a default assignment is something you might well do anyway. Either way we're saying "we know this is nothing" as of now. Of this, I do like the grouping factor. But, who am I... – Grant Thomas Feb 08 '13 at 08:42
I prefer this because it would also stop a dev (maybe who is using resharper or similar) from assuming the field can be made readonly. – weston Feb 08 '13 at 09:19
Can I use SuppressMessageAttribute http://msdn.microsoft.com/en-us/library/system.diagnostics.codeanalysis.suppressmessageattribute%28v=vs.100%29.aspx but I can't figure out how to generate the extremely verbose attr from the compiler warning? – bradgonesurfing Feb 08 '13 at 09:33
@bradgonesurfing: I'm not sure that it's used by the compiler - I'd expect it to be used by FxCop etc instead. I could be wrong though :) – Jon Skeet Feb 08 '13 at 09:35
1

@bradgonesurfing ["You should not use in-source suppressions on release builds to prevent shipping the in-source suppression metadata accidentally. Because of the processing cost of in-source suppression, the performance of your application can also be degraded by including the in-source suppression metadata."](http://msdn.microsoft.com/en-us/library/ms244717(v=vs.100).aspx) – weston Feb 08 '13 at 10:44
There's no need to pragma everything! See my answer below :) – Ana Betts Feb 09 '13 at 19:52

score 7 · Answer 2 · answered Feb 08 '13 at 19:40

7

Now that every platform has CallerMemberNameAttribute support in ReactiveUI, there's no need to suffer the oppression of your Obsessive Compulsive Compiler:

ViewPortViewModel _Trochoid;
public ViewPortViewModel Trochoid
{
    get { return _Trochoid; }
    set { this.RaiseAndSetIfChanged(ref _Trochoid, value); }
}

The other overloads are really unnecessary now, but I leave them in because removing them is a breaking change and therefore won't be done until ReactiveUI 5.0

answered Feb 08 '13 at 19:40

Ana Betts

73,868
16
141
209

The OP is already using CallerMemberNameAttribute - and setting the value by reflection: "However due to the magic that RaiseAndSetIfChanged performs through CallerMemberName" - I was assuming they didn't want to change how they used `RaiseAndSetIfChanged`. – Jon Skeet Feb 10 '13 at 09:02
If you use the Ref overload, it won't do the reflection :) – Ana Betts Feb 10 '13 at 22:58

score 4 · Answer 3 · answered Feb 08 '13 at 08:25

4

You could assign it a default for a reference type:

ViewPortViewModel _Trochoid = null;

answered Feb 08 '13 at 08:25

Grant Thomas

44,454
10
85
129

This works but feels wrong as I overwrite the value in the constructor. – bradgonesurfing Feb 08 '13 at 08:28
2

If you have a tool like resharper, doing this will cause it to tell you that the field can be made readonly, and you'll still have to put a comment to supress that. – weston Feb 08 '13 at 09:16

Suppress "Member is never assigned to" warning in C#

3 Answers3