How to avoid setting field values directly so to always trigger a setter, and PropertyChanged notifications

Question

I have a class which implements INotifyPropertyChanged. I have a property setter which triggers notification. But the C# compiler does not know/complain anything if I just use the field, and directly assign values. But if I do that property changed notification is completely useless. I am seeing this mistake being made quite often. SO my questions are

How to verify if this mistake (setting filed value instead of using setter) is made in a large solution,
How to force some kind of warning or errors when this happens

Since no question is complete without a code sample, here is the illustration of proplem

class Person : INotifyPropertyChanged
{
        private string personName;
        public string PersonName
        {
            get { return personName; }
            set { if(personName!=value)
                  {
                        personName = value;
                        this.OnPropertyChanged ("PersonName");
                  }
                }
        }
        public bool dummy()
        {
            personName = "not notified"; //need to detect/avoid this
        }
}

INotifyPropertyChanged itself state that what it can do. you are assigning value directly to a member variable not to the property. — Binson Eldhose, Jan 03 '14 at 10:41
Some avoid this recommendation like plague, but it does really help if you start your field names with an `underscore`, making your life a little easier. — Mat J, Jan 03 '14 at 10:51
You can't do this via `INotifyPropertyChanged` because the Property did not change. This is the kind of thing that you should catch in code reviews :) — Stephen Byrne, Jan 03 '14 at 10:58
Yeah, I am finding them in code reviews, but since we are one of the groups that Mathew referred, its hard to catch them. I think its time to change I guess. — Adarsha, Jan 03 '14 at 11:20
If the fact that change notification does not work when the code is tested and a code review is not enough for you then naming conventions (underscores) may help. I would enforce discipline rather than look at any kind of 'coded' solution to this. — BenjaminPaul, Jan 03 '14 at 12:09

score 2 · Accepted Answer · answered Jan 03 '14 at 11:31

Maybe you can try an extension.

Kind Of Magic automatically adds at compile time the necessary "raisers" for you. So you can use only Auto-Implemented Properties and avoid the private field.

It works like this:

Instead of write all code:

public string Name  
{ 
  get  
  {  
    return _name;  
  } 
  set  
  {  
    if (_name != value) 
    { 
      _name = value; 
      RaisePropertyChanged("Name"); 
    } 
  } 
}

Just use an attribute to do this work:

[Magic] 
public string Name { get; set; }

The extension have much more option. I think you should take a look.

Edit If you search more you can find even more extension that try avoid type all the pattern of INotifyPropertyChanged without lose functionality.

Awesome, I think that addin solves lots of my problem. Thanks for pointing that out. — Adarsha, Jan 03 '14 at 12:42

score 0 · Answer 2 · edited May 23 '17 at 12:28

Your code is OK. In this application properties are only WPF UI gateway. Use a following naming convention to recognize properties and fields simpler:

//Camel convention and beginning with underscore and small letter
private String _personName; 

//Camel convention and capital letter beginning
public string PersonName { get; set; }

By normal, in ViewModel properties do not have to be accessed: it is commands' prerogative. All you have to do in ViewModel is to initialize private fields in constructor.

That is not kind of potential error to raise up a warning, but it may be a first step to obfuscate code a much.

Of course if you are so worried about breaking MVVM pattern principles, there is a range of frameworks which cope with MVVM routine successfully.

Also you can find it useful to refresh MVVM knowledge with some guidelines.

How to avoid setting field values directly so to always trigger a setter, and PropertyChanged notifications

2 Answers2