11

I know that when using auto-properties, the compiler creates its own backing field behind the screen. However, in many programs I read to learn from, I see people explicitly write

private int _backingField;

public int Property { get { return _backingField; } }

What is the difference between above, and below?

public int Property { get; private set; }

I understand that its obvious to use the property when you actually have side-effects in the getter or setter, but that's often not the case. Also, I understand that you have to explicitly use the backing field in the case of structs, you can't access their members via properties.

The only difference I have been able to find is that the way of calling the value is different inside the class it is defined in. Is it then simple preference, or is there something more to calling a value through its property or by directly accessing the field? Simple conventions?

BartoszKP
  • 34,786
  • 15
  • 102
  • 130
Taelia
  • 591
  • 3
  • 20

1 Answers1

14

There's not much difference between those two snippets - you can't pass a property by reference, for example, but that's rarely an issue. However, if you want the field to be readonly, like this:

private readonly int _backingField;    
public int Property { get { return _backingField; } }

then there's a difference. The code I've written above prevents the value from being changed elsewhere within the class, making it clear that this is really meant to be immutable. I'd really like to be able to declare a read-only field with a read-only automatically implement property, settable only within the constructor - but that's not available at the moment.

This is rather confusing, by the way:

Also, I understand that you have to explicitly use the backing field in the case of structs, you can't access their members via properties.

What do you mean? You can definitely use properties within structs. Are you talking about backing fields which are mutable structs, i.e. the difference between:

foo.someField.X = 10;

and

foo.SomeProperty.X = 10;

? If so, I normally avoid that being an issue by making my structs immutable to start with :)

Jon Skeet
  • 1,421,763
  • 867
  • 9,128
  • 9,194
  • 1
    Using the XNA's Vector2 as an example, if I say public Vector2 TheVector { get; set; } I cannot call TheVector.X = 10; Instead, I must use the actual field. Something about passing by value/reference. (Do you have some reading material that clarifies passing by value/reference for c#, as a sidenote?) – Taelia Mar 10 '12 at 11:18
  • Also, if there is really no difference between my two examples, why do so many people still explicitly create a backing field (without real purpose)? – Taelia Mar 10 '12 at 11:22
  • @Taelia: Right, that's the case of a mutable struct - which I normally avoid. It's because the property returns a copy of the value. And I'm not going to try to give reasons for what other people do. – Jon Skeet Mar 10 '12 at 11:24
  • @Taelia Auto-properties were introduced in C# 3.0. Which can explain why some developers use auto-properties while some don't. As some developers who used earlier version might prefer the "old way". – Terkel Mar 10 '12 at 11:24
  • Alright, thank you both. I saw it happen so often it made me wonder if I was doing the right thing by not creating explicit fields. If it makes no difference, I'll keep writing code without them then. – Taelia Mar 10 '12 at 11:26