Just adding this because the question also has a vb.net tag, but in vb.net you need to specify a backer if you use private on either either get or set. So in vb.net it's actually less work to make the property readonly I think.
– user643192Feb 26 '13 at 7:08

An update for those reading this answer in 2016. C# 6.0 has introduced readonly auto-properties, which allow you to have a readonly property without a backing field: public string Name { get; }. If you don't want a mutable property, that's the preferred syntax now.
– AlexeyFeb 22 '16 at 14:04

4

One very good reason not to use private set is that it's not as immutable as we like to pretend it is. If you want to implement a truly immutable class, read only is a must.
– RubberDuckJul 7 '16 at 0:04

May be a performance reason to NOT use readonly. Seems to cause unnecessary copying of structs when accessing methods of a readonly struct field. codeblog.jonskeet.uk/2014/07/16/…
– TriynkoJul 31 at 21:52

This makes the Name property effectively Read Only to all outside code and provides an explicit Set method. I prefer the explicit Set rather than simply using the set on the Name property because you are changing the value when setting it. Normally if you set a property value, you expect to get the same value back when you call the get later on, which would not happen if you did your ToTitleCase in the set.

I believe 'private set' has special semantics in the compiler (not simply performing as a private accessor). Is this also the case with protected set? If not, where's the semantic equivalent to protected set if private set has special semantics? I haven't been able to find any documentation explaining this.
– SpragueMar 31 '12 at 9:30

1

+1 but I would call the method "Rename" instead of "SetName".
– MattDaveyOct 8 '12 at 14:07

Don't use the second example. The whole point of using a property - even if there is nothing going on beyond the getter getting and the setter setting - is to funnel all access through that getter and setter so that if you ever need to change behaviour in the future, it's all in one place.

Your second example abandons that in the case of setting the property. If you used that approach in a large, complex class, and later needed to change the behaviour of the property, you'd be in search-and-replace land, instead of making the change in one place - the private setter.

Whenever I've needed to change the access level of a setter, I've generally changed it to either Protected (only this class and derived classes can change the value) or Friend (only members of my assembly can change the value).

But using Private makes perfect sense when you want to do other tasks in the setter besides changing the backing value. As pointed out earlier, it's good design to not reference your backing values directly but instead only access them through their properties. That ensures that later changes you make to a property are applied internally as well as externally. And there's virtually no performance penalty to referencing a property vs its backing variable.

But to clarify, accessing a property is slower than accessing its backing variable. A property's getter and setter are methods that require a Call and a Return, whereas a property's backing variable is accessed directly.

That's why, in cases where a property's getter may be accessed many times within a block of code, the property's value is sometimes cached first (saved in a local variable) and the local variable used instead. Of course, that assumes the property can't be changed asynchronously while the block is executing.

Thank you for your interest in this question.
Because it has attracted low-quality or spam answers that had to be removed, posting an answer now requires 10 reputation on this site (the association bonus does not count).