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

Accepted answer
Score: 122

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.

Score: 64

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.

Score: 47

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
Score: 30

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.

Score: 30

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.

Score: 18

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.

Score: 12

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.

Score: 8

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.

Score: 5

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 :-(

Score: 5

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
Score: 2

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.

Score: 2

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

Score: 2

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.

Score: 1

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.

Score: 1

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.

Score: 1

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

public string Title { get; }


public string Title { get; private set; }

Is this what 1 you are referring to?

Score: 0

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.

Score: 0

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.

More Related questions