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?

Factious

Answer 1

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.

Wareroom

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... – Genisia

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. – Flyaway

Can I use SuppressMessageAttribute msdn.microsoft.com/en-us/library/… but I can't figure out how to generate the extremely verbose attr from the compiler warning? – Factious

@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 :) – Wareroom

@Factious "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." – Flyaway

There's no need to pragma everything! See my answer below :) – Unhallowed

Answer 2

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

Unhallowed

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. – Wareroom

If you use the Ref overload, it won't do the reflection :) – Unhallowed

Answer 3

You could assign it a default for a reference type:

ViewPortViewModel _Trochoid = null;

Genisia

This works but feels wrong as I overwrite the value in the constructor. – Factious

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. – Flyaway