[ACCEPTED]-C# 3.0 auto-properties — useful or not?-automatic-properties

We use them all the time in Stack Overflow.

You 3 may also be interested in a discussion of 2 Properties vs. Public Variables. IMHO that's really what this is a reaction 1 to, and for that purpose, it's great.

Yes, it does just save code. It's miles easier 13 to read when you have loads of them. They're 12 quicker to write and easier to maintain. Saving 11 code is always a good goal.

You can set different 10 scopes:

public string PropertyName { get; private set; }

So that the property can only be 9 changed inside the class. This isn't really 8 immutable as you can still access the private 7 setter through reflection.

As of C#6 you 6 can also create true readonly properties - i.e. immutable 5 properties that cannot be changed outside 4 of the constructor:

public string PropertyName { get; }

public MyClass() { this.PropertyName = "whatever"; }

At compile time that 3 will become:

readonly string pName;
public string PropertyName { get { return this.pName; } }

public MyClass() { this.pName = "whatever"; }

In immutable classes with a 2 lot of members this saves a lot of excess 1 code.

The three big downsides to using fields 1 instead of properties are:

1. You can't databind to a field whereas you can to a property
2. If you start off using a field, you can't later (easily) change them to a property
3. There are some attributes that you can add to a property that you can't add to a field

I personally love auto-properties. What's 12 wrong with saving the lines of code? If 11 you want to do stuff in getters or setters, there's 10 no problem to convert them to normal properties 9 later on.

As you said you could use fields, and 8 if you wanted to add logic to them later 7 you'd convert them to properties. But this 6 might present problems with any use of reflection 5 (and possibly elsewhere?).

Also the properties 4 allow you to set different access levels 3 for the getter and setter which you can't 2 do with a field.

I guess it's the same as 1 the var keyword. A matter of personal preference.

From Bjarne Stroustrup, creator of C++:

I 14 particularly dislike classes with a lot 13 of get and set functions. That is often 12 an indication that it shouldn't have been 11 a class in the first place. It's just a 10 data structure. And if it really is a data 9 structure, make it a data structure.

And 8 you know what? He's right. How often are 7 you simply wrapping private fields in a 6 get and set, without actually doing anything 5 within the get/set, simply because it's 4 the "object oriented" thing to do. This 3 is Microsoft's solution to the problem; they're 2 basically public fields that you can bind 1 to.

One thing nobody seems to have mentioned 7 is how auto-properties are unfortunately 6 not useful for immutable objects (usually 5 immutable structs). Because for that you 4 really should do:

private readonly string title;
public string Title
{
    get { return this.title; }
}

(where the field is initialized 3 in the constructor via a passed parameter, and 2 then is read only.)

So this has advantages 1 over a simple get/private set autoproperty.

I always create properties instead of public 3 fields because you can use properties in 2 an interface definition, you can't use public 1 fields in an interface definition.

Auto-properties are as much a black magic 5 as anything else in C#. Once you think about 4 it in terms of compiling down to IL rather 3 than it being expanded to a normal C# property 2 first it's a lot less black magic than a 1 lot of other language constructs.

I use auto-properties all the time. Before 5 C#3 I couldn't be bothered with all the 4 typing and just used public variables instead.

The 3 only thing I miss is being able to do this:

public string Name = "DefaultName";

You 2 have to shift the defaults into your constructors 1 with properties. tedious :-(

I think any construct that is intuitive 5 AND reduces the lines of code is a big plus.

Those 4 kinds of features are what makes languages 3 like Ruby so powerful (that and dynamic 2 features, which also help reduce excess 1 code).

Ruby has had this all along as:

attr_accessor :my_property
attr_reader :my_getter
attr_writer :my_setter

The only problem I have with them is that 6 they don't go far enough. The same release 5 of the compiler that added automatic properties, added 4 partial methods. Why they didnt put the 3 two together is beyond me. A simple "partial 2 On<PropertyName>Changed" would have 1 made these things really really useful.

Well with code snippets an auto-property 2 of the same name would be seven keystrokes 1 in total ;)

It's simple, it's short and if you want 4 to create a real implementation inside the 3 property's body somewhere down the line, it 2 won't break your type's external interface.

As 1 simple as that.

One thing to note here is that, to my understanding, this 5 is just syntactic sugar on the C# 3.0 end, meaning 4 that the IL generated by the compiler is 3 the same. I agree about avoiding black 2 magic, but all the same, fewer lines for 1 the same thing is usually a good thing.

In my opinion, you should always use auto-properties 9 instead of public fields. That said, here's 8 a compromise:

Start off with an internal field using 7 the naming convention you'd use for a property. When 6 you first either

• need access to the field from outside its assembly, or
• need to attach logic to a getter/setter

Do this:

1. rename the field
2. make it private
3. add a public property

Your client code 5 won't need to change.

Someday, though, your 4 system will grow and you'll decompose it 3 into separate assemblies and multiple solutions. When 2 that happens, any exposed fields will come 1 back to haunt you because, as Jeff mentioned, changing a public field to a public property is a breaking API change.

@Domenic : I don't get it.. can't you do 2 this with auto-properties?:

public string Title { get; }

or

public string Title { get; private set; }

Is this what 1 you are referring to?

I use CodeRush, it's faster than auto-properties.

To 1 do this:

 private string title;
public string Title
{
    get { return title;  }
    set { title = value;  }
}

Requires eight keystrokes total.

My biggest gripe with auto-properties is 6 that they are designed to save time but 5 I often find I have to expand them into 4 full blown properties later.

What VS2008 3 is missing is an Explode Auto-Property refactor.

The fact we have 2 an encapsulate field refactor makes the way I work quicker 1 to just use public fields.