Are there any more benefits, or perhaps drawbacks of the "new" way to define properties?

Question

Are there any further benefits to the "new", shorter way to handle properties, other than shorter code - like performance benefits, less memory usage etc.?

Writing

public string StrVariable { get; set;}

Rather than

private string strVariable;

public string StrVariable
{
    set
    {
        strVariable = value;
    }
    get
    {
        return strVariable;
    }
}

And are there any drawbacks - perhaps some would argue the code is less readable, less explicit?

Answer 1

Heres a link you may find useful.

Answer 2

One drawback I can see is if you want to do something else in the get/set routines. Increment a counter or something of that sort. Maybe validate the input if you haven't already.

Answer 3

One big drawback in a specific scenario - you lose control of the field name. This might sound insignificant, but it is a big problem if you are using binary serialization (via BinaryFormatter).

Other things:

• they can't be readonly at the field level
• for structs you need to call : this() in custom constructors

They do, however, do a fantastic job in 99% of cases - they express the code neatly, while leaving it possible to add extra implementation details later (by switching to explicit fields) without breaking calling code (except for the points above).

Answer 4

Collection properties are one issue as well. They are not initialized with Autoproperties.

Example:

public class foo
{
    public List<String> S1 { get; set; }

    private List<string> s = new List<string>();
    public List<String> S2
    {
        get { return s;}
        set { s = value; }
    }
}

foo f = new foo();
f.S1.Add("thing");
f.S2.Add("thing");

f.S1.Add will bomb with a nullref exception.