Should i use Auto-Implemented Properties instead of Fields ?

i was going through my code and changing some fields to private when i taught why don’t i just turn all the fields into auto-implemented properties, what do you guys think about that? is it better? or doesn’t have any disadvantages? and does it provide even a slightly better security? or a better code format?

If the value is meant to be accessed outside, then having a property with a private field or having a read only property makes sense.

If you’re just asking if you should make a property with both private, I wouldn’t bother typing it, personally.

IIRC, auto-properties can’t have initial values other than the default prior to C# 6, so unless you’re using Unity with the 4.6+ .NET compiler exclusively, I wouldn’t bother simply because that restriction will mean you have to use explicitly defined fields at times anyways, making the usage inconsistent.

As methos mentioned, if you need to access data externally, then definitely use properties (I personally never make public fields at all), but if you only need to access it internally, then only use properties (auto or otherwise) if it’s possible you may need to validate the getting and setting in some way.

But note there’s no difference - it’s simply a style issue. It’s like asking whether to indent 2 or 4 spaces.

If you have outside code playing with a dozen of your variables, it’s equally bad encapsulation whether those are real public vars, or simple properties, or auto-properties. And if you decide to add some checks, it’s the same either way (turn a pubic var into a property, or add checks to your property, or rewrite an auto-prop as a real prop. All just as simple and the same end result.)

1 Like

My code is a mess with no auto implemented properties. I don’t have any at all, nor do I care. I’m happy with the the game though.

If it was a library for asset store, I’d sing a totally different tune.

It might be “all just as simple” to change the code itself, but the consequences are of a different nature. If you use properties from the beginning, it’s not a problem and usually breaks no code at all.

Adding properties for fields that used to be public usually introduces problems that could have been avoided from the beginning. Either weird runtime bugs (keeping the field accessor for “backward compability”, i.e. allow callers to keep their code + handle checks themselves like they used to prior to the introduction of the property) or it may break some code (sometimes dependent on conventions).

I do it just like @DonLoquacious , there are no public fields in my code, except for some fields that are declared const or readonly.
Of course we’re not talking about high-performance and low level code, that’s a different topic.

@CloudFs
Maybe some clarification in regards to encapsulation, as I’ve seen a few of your threads that mention encapsulation and security concerns.

Encapsulation itself does not provide any higher security in terms of protecting the software against hacking attempts.
It’s solely a concept that helps to structure, hide and encapsulate internal state or sequences of actions (all of them a.k.a implementation details), which should usually not be of any interest for parts of a program that need to get/set/execute something.

then what should i be doing to have good encapsulation

First understand why you need encapsulation, then it’ll answer it for you. Hint: stack overflow

“what should i be doing to have good encapsulation”: Ha, yes, that’s my point - worrying about properties obscures the basics of Object Oriented thinking. Which is: hide the variables because you never want to think about them. The member functions do what you need, handling those grubby variables for you. Also called information hiding.

Of course, you only do that when needed. Some classes are fine as lists of variables. You write helpful functions (or properties, or whatever,) but you’re thinking of it as a variable holder. My long version is at taxesforcatses-dot-com in the “intro to programming section” under “classes as objects.” But what’s on stackoverflow looks fine, I guess.

“Adding properties for fields that used to be public usually introduces problems”: what I mean is a standard rewrite of “public int age;” as "private int _age; int age {get/set …}. if you’re setting age in client code and suddenly realize it shouldn’t ever be negative for anyone ever, it makes no difference whether age started as a property or a public variable. Either way you rewrite it as an age property with the not-less-than-zero check.

But I’m thinking “usually” in that sentence is to say a do-nothing property, even an auto-property, makes it more likely you’ll add checks as you think of them? It might. But that’s a style issue.

it’s okay you don’t need to answer or reply

i don’t think you guys understood me

i don’t want to change
public int age;
to
private int _age;
int age {get/set …}

i want to change it into an auto-implemented property
so
public int age;
to
public int age {get; set;}

Don’t worry, we did actually understand what you had asked. And it was answered multiple times.
The example that you quoted was part of a response to my comment about issues that could asrise when you start out with public fields and turn them into properties later…