Non-changed value and auto-implemented properties

Question

When implementing simple properties, you can make use of auto-implemented properties, to make the code look simpler, like this:

public int MyInt
{
    get; set;
}

Or you can implement it with a "manual" private field. When this is the case, I have often seen people checking for value changes before using set. Like this:

private int _myInt;

public int MyInt
{
    get { return _myInt; }
    set 
    {
        if value != _myInt
            _myInt = value;
    }
}

So my question is this: Is checking for the changed value (in the latter case) good for anything? And if it is, then what impact does this have on the auto-implemented properties?

Answer 1

You would use that check when you implement INotifyPropertyChanged
(You want to fire an event only when the value of the property actually changes, not simply when the setter is called.)

Answer 2

Is checking for the changed value (in the ladder case) good for anything?

Not really, at least not in the example you provided. Well, unless you have code that assigns to the property in a huge loop (hundred thousands), in which case, if checking the value is milliseconds faster than the assignment, then you will see a noticeable difference. I said "if", because I'm not sure it is the case for int, so you'll have to test it if you're interested in the answer.

However, in other scenarios, there could be a noticeable difference. For example, if the setter is more than just assigning the value.

Answer 3

You can´t do both, use an auto-implemented property and check its value. As soon as you introduce any logic into either the getter or the setter, it´s not any more an auto-implemented property.

The auti-implementing property is just a syntactic sugar for a getter/setter accessing a private backing-field as if you´d write this:

public int MyInt
{
    get { return _myInt; }
    set { _myInt = value; }
}

When you want to check if the new value even is valid you have to use a setter with some logic within. For example you may want to check if your integer is positive because your application can´t handle negative values. So you simply introduce that check in the setter.

set 
{
    if (value >= 0)
        _myInt = value;
}

As an aside you can´t define just one part (that is either the getter or the setter), you have to define both with braces. On the other side you can of course completely omit one of them, making your property readonly or write-only (although I can barely think of any use of the latter). Actually even properties are syntactic sugar for a get- and a set-method. So you can think of them as usual methods. Why shouldn´t you introduce any logic there? Of course properties tend to make people think that nothing special is happening within their setter or getter, and this is also what conventions suggest. However there´s actually nothing special on them except the fact that on auto-implementing properties your just accessing a backing-field which you can´t access in your code as it´s name isn´t known to the IDE, however it exist within the IL as shown here.

EDIT: To come back to your question. It won´t make a real difference if you´d introduce the logic for validation of the new value within the setter or before it, thus you can also write this:

int newValue = -1;
if(newValue >= 0)
    myInstance.MyInt = newValue;

But this could be quite messy and in particular breaks the DRY-priniciple as soon as you´d need to set the property somewhere else in your code and check it again. So it´s better to do it once, and only once (within the setter).

Answer 4

Lets assume MyInt is X location of your mouse, you have a infinite loop that takes mouse location every milisecond, and shows on a window. If you do not check you have to update window every miliseconds, when your mouse is standing still.

Most of the cases you do not need to check, even if it is the same value, value is changed. Do it when you have performance issues.