INotifyPropertyChanged Setter Style

In order to reflect changes in your data to the UI you have to implement INotifyPropertyChanged, okay. If I look at examples, articles, tutorials etc most of the time the setters look like something in that manner:

public string MyProperty
{
  //get [...]
  set
  {
    if (_correspondingField == value)
    {
      return;
    }
    _correspondingField = value;
    OnPropertyChanged("MyProperty");
  }
}

No problem so far, only raise the event if you have to, cool. But you could rewrite this code to this:

public string MyProperty
{
  //get [...]
  set
  {
    if (_correspondingField != value)
    {
      _correspondingField = value;
      OnPropertyChanged("MyProperty");
    }
  }
}

It should do the same (?), you only have one place of return, it is less code, it is less boring code and it is more to the point ("only act if necessary" vs "if not necessary do nothing, the other way round act").

So if the second version has its pros compared to the first one, why I see this style rarely? I don't consider myself being smarter than those people that write frameworks, published articles etc, therefore the second version has to have drawbacks. Or is it wrong开发者_运维技巧? Or do I think too much?

Thanks in advance

---

I find the second example more readable personally. I think one of the reasons the first example has become widespread is that Resharper will prompt to use this style (and automatically do the conversion), with the rationale that it "reduces nesting". Which is correct, but in simple cases like these I think readability is more important.

It comes down to a fundamental difference of opinion - there are those programmers out there who think that there should only ever be one "return" - one single exit point at the end of the method. Then there are those who think that there should always be an "early exit" if at all possible, which can lead to multiple "returns" throughout the method. Which do you prefer? :)

---

I see the second style much more often than the first... but anyway it doesn't matter, the behavior is exactly the same. And no, I don't think there is any drawback with the second approach. It's just a matter of personal preference, choose the one you find most readable.

---

Same as Thomas Levesque. I use myself the second one in my code, and I have seen it quite often. Both approach should perform the same.

---

It reduces nesting.

In your example, its pretty clear, and its just a matter of taste, but it is much clearer when used in consecutive manner, as you can see here:

Invert "if" statement to reduce nesting

Usually I don't care if I get an event when the value is the same, so I leave that part out:

public string MyProperty
{
  get { return _correspondingField; }
  set { _correspondingField = value; OnPropertyChanged("MyProperty"); }
}