13

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 new 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?

skaffman
  • 398,947
  • 96
  • 818
  • 769
Biggert
  • 278
  • 4
  • 21
  • from a design point of view, it is better to keep what you have, it helps distinguish what is private, and what is public just by looking at the code. – MBen May 25 '11 at 14:01
  • possible duplicate of [What are the benefits of using properties internally?](http://stackoverflow.com/questions/2884715/what-are-the-benefits-of-using-properties-internally) – nawfal Jun 03 '13 at 17:51

6 Answers6

11

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.)

LukeH
  • 263,068
  • 57
  • 365
  • 409
9

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.

H H
  • 263,252
  • 30
  • 330
  • 514
  • but later adding logic requires creating a private member to back the property... and you can't actually guarantee other code won't access that member directly – Robert Levy May 25 '11 at 14:13
  • @Robert: true but at the point of adding the logic you know it will be used properly by existing code. That's all. – H H May 25 '11 at 14:17
  • At least in VS 2015 you also get a reference count to the auto variables. – Godspark Jan 29 '16 at 08:58
3

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.

Robert Levy
  • 28,747
  • 6
  • 62
  • 94
  • If I could accept more than one answer, I would accept this one too. I think both answers in conjunction provide some good reasoning to avoid this behavior. – Biggert May 26 '11 at 21:12
  • This is why prefixing private backing members useful. Traditionally, I use the _ , since it will prevent Intellisense from grabbing the private member when writing code, but that's a bad practice in c++. So I'm considering a different prefix, like "p_" for private backing stores that should not be accessed directly. What I'd really like to see is a property-local scope for backing fields, kind of like the way "value" is implicitly declared. Perhaps "thisp". – TomXP411 Feb 05 '19 at 19:42
2

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.

Bueller
  • 2,336
  • 17
  • 11
  • makes sense for public properties but not for private - see my answer – Robert Levy May 25 '11 at 14:13
  • I see slower code execution and larger executables as reason enough not to do something like this. Adding unnecessary property declarations may mean that the program generates extra code to access those member variables. But then, I come from the 8-bit era where every byte counted. – TomXP411 Feb 05 '19 at 19:44
0

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;}

TomXP411
  • 899
  • 9
  • 14
0

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.

  1. This will not be useful, In case you don't have any logic to write in your properties for retrieving and returning values.
  2. 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

Pankaj
  • 9,749
  • 32
  • 139
  • 283