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