Using a private auto property instead of a simple variable for a programming standard_问答_开发者

In a discussion with a peer, it was brought up that we should consider using auto properties for all class level variables... including private ones.

So in addition to a public property like so:

public int MyProperty1 { get; set; }

Our private class-level variables would look like this:

private int MyProperty2 { get; set; }

Instead of:

private int _myProperty2;

I'm on the fence about why someone would want to do this but I can't decide if my reluctance to accept this is because of my own internal brainwashing with how I write my code to the same programming standards and naming conventions I've used for 10 years or because I've never seen this before (for a reason).

I realize it's extra code to type but to be honest, when using auto-properties, I don't think I've ever typed it out due to the 'prop' and 'propg' snippets so it'd be very simple to set up a n开发者_如何学编程ew snippet to create a private auto property so the extra code doesn't bother me too much since I never have to type it.

Other than aesthetics which may just be my subconscious, are there any issues that could result from using fully private auto properties? Are there any good reasons to do this or not to do it? I've seen a lot of code in my day on stackoverflow, codeplex, codeproject, etc. and I've never seen anyone use this standard.... is there a reason why?

Private auto-properties are completely pointless, in my opinion. What value does a private auto-property provide that a plain field doesn't?

(It's different when the auto-property is only partially private -- eg, a public/protected getter with a private setter -- or when you use a private non-automatic property to enable you to wrap additional code around the getter/setter.)

This does not make too much sense.

I can think of a 'benefit':

you can later add logic to the getter and/or setter and be sure it is always passed

but frankly your classes should not become so big that this is useful.

"are there any issues" ?

Your properties won't work as arguments to ref or out parameters.

It's not nearly as useful for privates as for publics.

Suppose you took your automatic private property and later built some logic into it (being able to do that without breaking anything is the whole point of auto props)...

This would require you to create a private backing member for the property to wrap.

So now you've got two different private ways (member and property) of doing the same thing though one has hidden side effects (the property) and you've now also got the problem of ensuring none of your other methods in the class access that member directly.

Ends up being much more of a headache than just using a private member from the beginning.

What this strategy will do for you is provide an opportunity to put any future changes into the previously autogenerated private property without affecting any of the other code that gets or sets your private property. I personally haven't used this much but it can be beneficial in a case where changes to handling may occur. It also standardizes the code so that fields are always accessed by properties. There are no real drawbacks but it is not really much benefit in most situations either. I think style is really the biggest driver in most situations.

In a discussion with a peer, it was brought up that we should consider using auto properties for all class level variables... including private ones.

This will not be useful, In case you don't have any logic to write in your properties for retrieving and returning values.
Besides point 1, you have read only property So you can directly go with

public int MyProperty1 { get; set; }

Moreover it reduces your line of code and Quick Implementation

I'm a firm believer in KISS. I never use a property when a field will do, and I see very little reason to use private accessors (get).

The primary purpose of a property is to be a public accessor for private data. So for simple propreties that do nothing but set or get a value, private accessors and setters make no sense.

Having said that, when you need to transform the data as it's being read, or when you need to perform a side effect when updating the value, you should use a field. Does changing your value raise an event? Then a field is a no-brainer. But then, that's not an auto field that you're declaring with {get; set;}