Question: I doubted to post this question to the general StackOverflow, but it is suggested to not post opinion-based questions and this might be one. And ofcourse, this is the software engineering department. Microsoft Docs only describes the how, not the why.

When should one use a:

* property with a `{ get .... ; }` and a [backing field](https://docs.microsoft.com/en-us/dotnet/csharp/properties#attaching-attributes-to-auto-implemented-properties) or;
* a property with a `{ get .. ; private set .. ; }`

Why would you want to show a user of your implementation then a property cannot be set with a literal assignement?

This might be the same topic of the choice between a property named `Result` with a calculation in the Get-method, or a plain method `GetResult()` returning thesame string.

Answer: 
> 
> * property with a `{ get .... ; }` and a backing field
> * a property with a `{ get .. ; private set .. ; }`
> 
> 
> 

Note that your bullet points aren't quite correct. If you're using an auto property (i.e. not having an explicitly defined backing field), then the second bullet point's getter and setter should not have a body.

Once you explicitly define the body of the getters and setters, you're no longer using an auto property and you are required to either have a backing field or wire it to do whatever you need it to do.

Good practice dictates that properties should represent a stored (get) and storeable (set) state, so any getter or setter with an explicit body should refer to *some* kind of state, e.g. a backing field, property, external resource, ...

---

As the name implies, auto properties *automatically* use a backing field. `get;` and `set;` will be translated into the default `get => _myGeneratedBackingField;` and `set => _myGeneratedBackingField = value;` statements respectively.

I'm unsure whether `private set;` get translated to `private set => _myGeneratedBackingField = value;` or if the assignments to your property instead get rewired to the backing field. I would assume the former but either is possible. But it functionally does not make a difference in either case.

*At runtime*, it makes no difference whether you explicitly use a backing field or not. The only difference is during *design time* (i.e. while coding), where's it's either a matter of preference (how you want to use it) or fringe cases such as reflection which depend on the existence of a particular field in your class.

Auto properties are just syntactic sugar. Nice to work with, but wholly irrelevant post-compilation.
This is a matter of preference. I do not like auto properties much, it leads to unnecessarily obscure code. I do use them sometimes but only for the most basic DTO-type of classes.

My problem with them is that the data members of a class are no longer guaranteed to be listed first. If you apply StyleCop you can be sure all data members will be the first thing you see when you study a class. If they are not there, they do not exist. What you will see before the first constructor is all of the class's data, period... Unless there are some of those hidden handy-dandy differently styled auto properties defined further down in the code. I hate that. When I encounter them I often just think "they (C# designers) should never have done this, people cannot handle the responsibility, this convenience is not worth the trouble".