Private Set or Private member?

I was wondering what's considered the C# best practice, private/protected members with public getters, or public getters with private/protected setters?

       public int PublicGetPrivateSetter
       {
            get;
            private set;
        }

        private int _privateMember;

        public int PublicGetPrivateMember
        {
            get { return _privateMember; }
        }

I feel that using a private member is more explicit in your code that it's a private setter (using naming conventions). On the other hand using private setters gives you an option to use virtual (protected), write less code, has less room for mistakes and can give you an option to add a side effect later on if you need to.

I couldn't find what's considered a best practice, or even if one is considered better than the other. From what I've seen usually 80% of the time (from code that I'VE seen) people DONT use private setters... I'm not sure if this is because people don't know about private setters, or because it's considered better to actually 开发者_JS百科use private members.

EDIT:

Indeed, other benefits which I forgot about when using private members is default values and the use of readonly.

I prefer to use auto-implemented properties unless the default implementation doesn't do what I want. So in this case, since the auto-implemented property does what you need, just use that:

public int Foo { get; private set; }

However another situation is if you want to make the field readonly (meaning that the only place where the field can be set is in the constructor). Then you need to define the backing field and mark it readonly as this isn't supported by auto-implemented properties:

private readonly int foo;

public int Foo
{
    get { return foo; }
}

There is no best practice I'm aware of. I know automatic properties were mainly to make things easier even more easier for code generation and LINQ related stuff.

For me, I start with automatic properties and refactor later if needed. Depending on the need I may change something to virtual or protected as you mentioned, or maybe refactor to use a variable (When I want to refactor the set accessor to have some logic.

Its the same thing. In the first example, the compiler generates the backing store. In the second, you generated the backing store. Since the implementation is internal to the class, refactoring one into the other is not a big deal. Tools like Resharper make that trivial. The reason you probably haven't seen private setters that much is that its a C# 3.0 feature.

There's nothing wrong with private setters. In most case, it's used with auto properties to make the property readonly outside the object's scope.

Conceptualy speaking, it doesn't change anything. It's mostly a matter of taste.

I personnally use the private setter because I'm lazy and use the propg snippet a lot. (propg tab tab)

Also, most of the time I end up setting dirty flags and binding events to those properties, so I might as well do a part of the work right now. If you ever need to add a setter later, it's much easier if the code is written without using the member behind since the beggining as it will be less code to change.

There is no good answer to this question. the best pratice is to follow our compagnie nomenclature and if your alone then the way you prefer

In my opinion there is no best practice and very little (if any) difference in the resulting compiled code, it really just depends on your needs or own likes/dislikes. If you're following your group's naming standards and meeting requirements (e.g. don't need to propagate a change notification) then it shouldn't matter.

An advantage of private fields is that you can define a default value in the same place as your declaration. In an auto-implemented property you'll have do define the default in the constructor if it's not null or the type's default value.

However, I still like private setters. But we usually don't use auto-implemented properties since our setters usually have a richer functionality - e.g. property update notifications, logging, etc.