Why does resharper suggest readonly fields - c#

Why is ReSharper suggesting readonly field for 'settings' in my example below?
If I understand correctly, you should use readonly modifier if you change this field only in constructor, but in my example I also change it in another method in the same class.
What am I missing?
public partial class OptionsForm : Form
{
private Settings settings;
public OptionsForm(Settings s)
{
settings = s;
}
private void SaveData()
{
settings.ProjectName = TextBoxProject.Text;
}
}

When a reference type is declared as readonly, the pointer is immutable, but not the object it points to. This means that:
a reference type data member can be initialized in order to point to an
instance of a class, but once this is done it's not possible to make it
point to another instance of a class outside of constructors
the readonly modifier has no effect on the object the readonly data member
points to.
Read a detailed article on this
Mark a C# class data member as readonly when it’s read only

Remember the primary reason for coding standards and design patterns is to make to easier for people to understand your code.
By marking a field as “readonly” you
are telling the reader of the class
that they don’t need to consider how
the value of the field is changed.
However as the object the readonly field points to can have it’s state change, marking a field as readonly can be misleading at times. So think about weather it helps the reader (e.g a person) of your code understand your design or not.
If the values in the object that the field points to changes within the object lifetime, then I don’t think a field should be marked read-only. (E.g the object pointed to should be behave as if it is immutable by the time the contractor on your class is called)
(However there are some exceptions, e.g it is OK to use a read-only field to point to a logger even thought the logger does change the state of the log file.)

ReSharper suggests making "settings" readonly:
readonly private Settings settings;
public OptionsForm(Settings s)
{
settings = s;
}
because, upon scanning your code it concludes that your "settings" field only occurs in the constructor for this same class.
If howerver you were to provide a partial class or some other code in this class that modified "settings", it would no longer suggest it was readonly.
Once marked readonly the compiler will flag as warnings various misuses of the field, such as:
The left-hand side of an assignment must be an l-value
which is the same error you get when you attempt to assign a value to a constant.
also the use of ref and out parameter modifiers are limited.
By following ReSharpers suggestion you will be warned by the compiler if you attempt to misuse a field that you really intend not to change after initialization.

You aren't changing settings outside of the constructor, the object is the same one in SaveData. The object properties might be changing but not the object reference, so it seems to make sense from a Resharper perspective.

The SaveData() method does not change the settings variable, it changes one its properties. The contents of settings (what it refers to) is only set in the constructor.

Actually, you're right and Resharper is wrong. A field should only be marked readonly if it is immutable in its entirety. In your example if you make it readonly and enable Microsoft's Code Analysis it will warn you that Settings has mutable properties.

This seems to be a bit strange, I can't imagine that Eric Lippert et al, didn't consider the obvious fact that making a reference immutable doesn't make instance pointed to by the reference immutable, though the mentioned Code Analysis rule does support the view of those above (http://msdn.microsoft.com/en-us/library/ms182302(v=VS.100).aspx).
It still doesn't really make any sense. If mutable instances should not be readonly, then, in my view, it should be a compile-time error, seems rather pointless otherwise.
I can see the use of making a reference immutable, rather than the instance it points to.

Related

Properties and auto-implementations

I'm using .NET 4.5 in a VSTO addin for outlook 2013. I'm having some trouble fully grasping properties and accessors. Auto-implemented accessors which I assume are when you just write get; set; rather than get { //code }, etc. are also giving me trouble. I have a dictionary I use internally in my class. Here is my code:
private Dictionary<string, string> clientDict { get; set; }
private Dictionary<string, string> clientHistoryDict { get; set; }
then later on:
clientDict = new Dictionary<string, string>();
clientHistoryDict = new Dictionary<string, string>();
I am using the same names as the properties in the code later on, within the same class.
I never actually write:
private Dictionary<string, string> _clientDict; // etc.
to create the variables I just was using the property directly.
I tried changing my code to do this, and I had some issues and realized my understanding of properties is a bit mixed up.
Here are a few questions I need clarified that I can't seem to find the correct answer to.
First, is there any reason to use a private property? My dictionaries are never accessed outside of the class or in any derived classes so is there a reason to even use properties? I don't use any special validation or anything in the setter or anything like that.
Second, when I tried to change my code to use variables and then access them via the properties like your typical property example would, I ran into problems. I found an example where the getter was set to return _clientDict, but the setter was just set; It gave me the error: that I must give set a body because it's not abstract or partial. Why would it not auto-implement the setter for me in this instance?
Last, when I call new on the properties in the same class that it is declared in, what is the difference between doing that with a property and a normal variable of the same type? Do properties differ at all from variables in that case? Is it bad practice to use properties this way when it should be accomplished with private variables?
These may be some misguided questions but I can't find any other place that has the information to help me understand these distinctions. I've been playing around with properties to try and figure all of this out but I could use so me assistance.
First, is there any reason to use a private property?
Usually, no. Properties are great for encapsulation. One advantage (there are many more) of using a property is that it can do validations before assignment. When you have something private, you usually don't need to protect things from yourself. Also, properties have the advantage of setting different accessors (private, protected, etc), where fields do not.
Why would it not auto-implement the setter for me in this instance?
We have to understand that auto-implemented properties aren't black magic. The compiler will generate a private backing field for us, instead of providing one ourselfs. From his point of view, he sees that you have a getter that returns a private field, but the setter is automatic, thatusually would indicate some kind of logical error in your code. Why would you return one value but set a completely different one? When you create a property with a backing field, you have to provide both the getter and setters, those are the rules.
when I call new on the properties in the same class that it is
declared in, what is the difference between doing that with a property
and a normal variable of the same type?
Semantically, Nothing. new belongs to the type being constructed and will emit a constructor call. The difference is once the newly created object is assigned. A field will cause the compiler to emit a stfld opcode. For a property it'll emit a call to invoke the property setter. When you access a property, the compiler will end up calling get_YourPropertyName vs a ldfld on the field.
Is it bad practice to use properties this way when it should be
accomplished with private variables?
I wouldn't call it bad practice, but I would find it a bit weird to have a private property.
For more insights on fields and properties, see What is the difference between a Field and a Property in C#?
Is there any reason to use a private property?
No - that's the whole point of auto implementation. It saves you having to write all that extra code when all you want to do is get or set what's in the private member variable. .Net handles the creation of the shadowing private member variable behind the scenes.
When I tried to change my code to use variables and then access them via the properties like your typical property example would, I ran into problems. I found an example where the getter was set to return _clientDict, but the setter was just set; It gave me the error: that I must give set a body because it's not abstract or partial. Why would it not auto-implement the setter for me in this instance?
My understanding is that it's all or nothing with auto implementation. (Open to correction there though). That said I have seen code compile with the set block simply defined as set { }. Edit: Just to clarify the set { } block won't actually set the value, it essentially swallows the call and does nothing - it will compile though.
When I call new on the properties in the same class that it is declared in, what is the difference between doing that with a property and a normal variable of the same type? Do properties differ at all from variables in that case? Is it bad practice to use properties this way when it should be accomplished with private variables?
There is no real difference as far as I am aware. The exact same thing is happening, it's just that .Net is handling the plumbing for you.

Which is better between a readonly modifier and a private setter?

I've been working on creating a class and suddenly a thought came to my mind of what is the difference between the two codes:
public readonly string ProductLocation;
AND
public string ProductLocation
{
get;
private set;
}
Can you guys give me idea when to use the following better. thanks.
The first one is a read-only field, while the second one gets compiled as a pair of methods (and all reads of the property ProductLocation gets compiled into calls to the corresponding get method and writes to it gets compiled into calls to the set method; internally, these methods will read from / write to an internal, automatically generated, non-read-only field). I'd say the most important difference is thread-safety! (how? read on!)
The basic usage of the class will look exactly the same: code in other classes will only be able to read the value, not change it. Also, the code to read the value will look exactly the same (for example, print(myInstace.ProductLocation); here, you cannot tell how it has been declared, cool, eh?)
The first, most trivial difference is that the property with private setter allows for instances of the same class to modify the value, while in the case of the readonly property, not even the object itself will be able to change the value.
Now, for the thread-safety. The readonly attribute on the field will change its memory visibility semantics when you are working with multiple threads (just like Java's final fields).
A readonly field can only be assigned to at declaration or in the constructor. The value assigned to a readonly field cannot be changed (at least not in a normal way) and it is guaranteed that every thread will see the correctly, initialized value after the constructor returns. Therefore, a readonly field is inherently thread-safe.
To achieve the same thread-safety with the property, you'd have to add some synchronization on your code, which is error-prone. It might lead to dead-locks, data races or reduced performance, depending on the case, and especially if you are not experienced.
So, if the value represents something that semantically cannot be changed after the object's construction, you should not declare a private setter (this would imply that the object might change it). Go for the readonly field (and maybe declare it private and declare a public property with only a getter accessing the field! This is actually the preferred form, since it is not good to expose fields, it is better to only expose methods -- there are many reasons explaining why in this answer)
With C# 6.0 auto-property initializer there is less boilerplate way of doing
private readonly string productLocation;
public string ProductLocation { get { return productLocation; } }
Which is
public string ProductLocation { get; }
This is readonly. Only initialized from constructor or inline. It cannot be edited after initialization. (Immutable from anywhere)
However, if you use private set;
public string ProductLocation { get; private set }
This is readonly from outside. But can be initialized anytime anywhere within the class itself. And can be edited within its life cycle by the class itself. (Mutable from class, immutable from outside)
Generally, it is not encouraged in .NET to expose member fields publicly, those should be wrapped by a property. So let's assume you might have
private readonly string productLocation;
public string ProductLocation { get { return productLocation; } }
vs
public string ProductLocation { get; private set; }
In this setup, and ignoring what one might be able to accomplish via reflection, the semantics are that in the first case, the productLocation variable can only be initialized in place and in the class constructor. Other members of the class cannot alter the value. External consumers have no ability to set the value.
In the second version, external consumers continue to have no access towards setting the value. However, the class itself can change the value at any time. If all you have is a DTO (that is, a class that only transports data, it has no logic expressed via methods), then this is essentially not all that different from the readonly version. However, for classes with methods, those methods could alter the value behind ProductLocation.
If you want to enforce the concept of an immutable field post-construction, use readonly. But for a DTO, I might go for the private set; option, mainly because it is less boilerplate code.
The first one (using readonly) will mean that the object can't even modify its own field's value, once the object has been instantiated, and others can never modify it.
The second one (using private set) will mean that object can modify the value of its field after it's been instantiated, but others can never modify it.
I would use the former for something that you know will not change, and use the latter for something where the value may change, but you don't want others to change it.
The first is a field whose value can be set only at instantiation.
The second is a property whose value can be set at any time (but only by its containing object).
Correction: The property can be set at any time by any instance of the same class (and not only by its containing object).

Why ever use fields instead of properties?

I'm fairly new to C#, and I think properties are a wonderful thing. So wonderful, in fact, that I can't see any real advantage to using fields, instead. Even for private fields, it seems like the flexibility and modularity that properties offer can at best save you serious headaches, and at worst have no effect at all.
The only advantage I can see for fields is that you can initialize them inline. But most of the time, you want to initialize them in the constructor, anyway. If you aren't using inline initialization, is there any reason not to use properties all the time?
Edit: Some people have brought up the need to back up properties with fields (either explicitly or automatically). Let clarify my question: Is there any reason to use fields except to back up properties? I.e., is there any time that SomeType someField; is preferable to SomeType SomeProperty { get; set; }?
Edit 2: DanM, Skurmedel, and Seth all gave really useful answers. I've accepted DanM's, as it is the most complete, but if someone were to summarize their responses into a single answer, I'd be happy to accept it.
Typically, properties need a backing field unless they are simple getter/setter "automatic properties".
So, if you're just doing...
public string Name { get; set; } // automatic property
...you don't need a field, and I agree, no reason to have one.
However, if you're doing...
public string Name
{
get { return _name; }
set
{
if (value = _name) return;
_name = value;
OnPropertyChange("Name");
}
}
...you need that _name backing field.
For private variables that don't require any special get/set logic, it's really a judgment call whether to do a private automatic property or just a field. I usually do a field, then, if I need it to be protected or public, I will change it to an automatic property.
Update
As noted by Yassir, if you use automatic properties, there's still a field lurking behind the scenes, it's just not something you actually have to type out. So, the bottom line is: properties don't store data, they provide access to data. Fields are what actually hold the data. So, you need them even if you can't see them.
Update 2
Regarding your revised question...
is there any time that SomeType someField; is preferable to SomeType SomeProperty { get; set; }?
...one thing that comes to mind: If you have a private field, and (according to convention for private fields) you call it _name, that signals to you and anyone reading your code that you are working directly with private data. If, on the other hand, you make everything a property, and (according to convention for properties) call your private property Name, now you can't just look at the variable and tell that it is private data. So, using only properties strips away some information. I haven't tried working with all properties to gauge whether that is crucial information, but something is definitely lost.
Another thing, more minor, is that public string Name { get; set; } requires more typing (and is a little messier) than private string _name.
Just try using a Property when using ref/out args:
someObject.SomeMethod(ref otherObject.SomeProperty);
It won't compile.
Properties are a wonderful thing -- but there is overhead associated with property access. Not necessarily a problem, but something to be aware of.
Avoiding Overuse of Property Getters and Setters
Most people don't realize that property getters and setters are similar to methods when it comes to overhead; it's mainly syntax that differentiates them. A non-virtual property getter or setter that contains no instructions other than the field access will be inlined by the compiler, but in many other cases, this isn't possible. You should carefully consider your use of properties; from inside a class, access fields directly (if possible), and never blindly call properties repeatedly without storing the value in a variable. All that said, this doesn't mean that you should use public fields!
Source: http://dotnet.sys-con.com/node/46342
If you want to have something readonly you pretty much have to use a field as there is no way to tell an automatic property to generate a read-only field.
I do this quite often.
Contrived example:
class Rectangle
{
private readonly int _width;
private readonly int _height;
public Rectangle(int width, int height)
{
_width = width;
_height = height;
}
public int Width { get { return _width; } }
public int Height { get { return _height; } }
}
This means nothing inside of Rectangle can alter the width or height after construction. If one tries to the compiler will complain.
If I instead had used an automatic property with a private setter the compiler wouldn't protect me from myself.
Another reason I see is, if a piece of data doesn't have to be exposed (stay private) why make it a property?
While I agree with what I perceive as the "intent" in David Basarab's statement : "There is no reason to publicly expose fields," I'd like to add a slightly different emphasis :
I'd modify the quote from David above to read : "There is no reason to publicly expose fields ... outside a class ... except through the conscious choice of encapsulating the fields in Properties through which access is rigorously controlled.
Properties are not simply a "veneer" of syntax over Fields "tacked onto" C# : they are a fundamental language feature designed for good reasons including :
controlling what is exposed and not exposed outside classes (encapsulation, data hiding)
allowing certain actions to be performed when a Property is accessed or set : actions that are best expressed in the Property 'get and 'set, rather than being "elevated" to externally defined methods.
Interfaces by design cannot define 'fields : but can define Properties.
Good OO Design means making conscious choices about "state" :
local variable fields : what state is private to a method and transient : local variables typically only valid within the scope of a method body, or even with as "narrow a lifespan" as within the scope of something like a 'for loop. Of course you can regard parameter variables in a method as "local" also.
class instance fields : what state is private to a class, and has independent existence for each instance of a class, but is most likely required to be used in several places in the class.
static instance fields : what state will be a property of the class only, independent of the number of instances of the class.
state deliberately and consciously exposed "outside" the class : the key idea being that there is at least one level of indirection interposed between the class and "consumers" of the data the class exposes. The "flip side" of "exposure" is, of course, the conscious intention of hiding (encapsulating, isolating) implementation code.
a. via public properties : all aspects of this well-covered in all the other answers here
b. via indexers
c. via methods
d. public static variables are usually found in utility classes, which are often static classes.
Suggest you review : MSDN on 'Fields ... MSDN on Properties ... MSDN on Indexers
I don't see why you'd use private autoproperties. What advantage is there to
private int Count {get; set;}
over
private int count
Fields and properties are not interchangeable. I guess what you're saying is accessing private fields through private properties. I do this when it makes sense but for the most part, it's not necessary. The JIT optimizer will inline access to a private field through a private property in most cases anyway. And wrapping a private field in a private property is not considered a breaking change anyway since private members are not a part of your interface.
Personally, I would never expose any protected/public instance fields. It's generally acceptable though to expose a public static field with a readonly modifier as long as the field type is itself immutable. This is often seen with SomeStruct.Empty static fields.
As others have noted, you will need a private backing field for properties anyway.
Also there is a speed advantage in using fields over properties. In 99.99 % of the cases it won't matter. But in some it might.
Fields are the only place you can store state. Properties are actually just a pair of methods with special syntax that allows them to be mapped to the get or set method depending on how they're being used: if a property modifies or accesses state, that state still has to be stored in a field.
You don't always see the fields. With C# 3 automatic properties, the field is created for you by the compiler. But it's still there. Furthermore, automatic properties have some significant limitations (e.g. no INotifyPropertyChanged support, no business logic in setters) that mean they're often inappropriate, and you need to create an explicit field and a manually defined property anyway.
As per David's answer, you're right if you're talking about an API: you almost never want to make the internal state (fields) part of the API.
The syntax for fields is a lot quicker to write than for properties, so when it's safe to use a field (private to the class) why not use it and save that extra typing? If auto-implemented properties had the nice short concise syntax and you had to do extra work to make a plain old field, people might just start use properties instead. Also, it's a convention now in C#. That's how people think, and it's what they expect to see in code. If you do something different form the normal, you will confuse everyone.
But you could ask why the syntax for fields doesn't create an auto-implemented property instead of a field, so you get the best of both worlds - properties everywhere and a concise syntax.
There's a very simple reason why we still need to have explicit fields:
C# 1.0 didn't have all these nice features that we have now, so fields were a fact of life - you couldn't really live without them. Lots and lots of code relies on fields and properties being visibly different things. It simply cannot be changed now without breaking tons of code.
I would suspect also that there are performance implications, but perhaps that can be solved by the jitter.
So we're stuck with fields forever, and since they're there and they've taken the best syntax, it makes sense to use them when it's safe to do so.
There is no reason to publicly expose fields.
If you public expose a field you can't change the source of the information, from inline defination to configuration file without refactoring.\
You could use a field to hide internal data. I rarely favor that, I only use fields when I am doing something to hide publicly and using it in a property. (i.e. I am not using Automatic property generation)
Speed. If a field gets set or read billions of times over the course of a simulation then you want to use a field and not a property to avoid the overhead och a sub routine call. Conforming to OO (DDD?) as far as possible, in these instances, I'd recommend resorting to fields only in class dedicated to representing some sort of "value" like person. Logic should be kept to a minimum. Rather, have a personcreator or a personservicer.
But if you have these issues then you're probably not programming c++ and not c#, aren't you?
There are several good (partial) answers by #Seth (fields perform better, so in a private context you might as well use that to your benefit when it makes sense), #Skurmedel (fields can be readonly), #Jenk (fields can be used for ref/out). But I'd like to add one more:
You can use the streamlined initialization syntax for setting the value of a field, but not a property. i.e.:
private int x = 7;
vs
private int x { get; set; }
// This must go in the constructor, sometimes forcing you to create
// a constructor that has no other purpose.
x = 7;

Disadvantages of using properties only with no corresponding fields in .NET?

I have classes which have automatic properties only like public customerName {get; set;}. They are public because they are accessed outside the class. They can also be accessed inside the class. They offer good encapsulation and better debugging. I can put a breakpoint on one if I need to know who is accessing it and when.
My question is what are the disadvantages of using properties only with no corresponding fields? I can make the setter or getter private, internal.. etc which means I also have flexibility of scoping it when needed.
Serialization with BinaryFormatter - you have big problems if you need to change your property to a "regular" property later, for example to add some validation / eventing /etc - sinc BinaryFormatter uses the field names. And you can't duplicate this, since the field name the compiler generates cannot be written as legal C#.
Which is a good reason to look at a contract-based serializer instead. See this blog entry for more info.
You can't create truly read only property, because you have to define both setter and getter. You can only use private setter to achieve pseudo-readonly property from outside.
Otherwise, as said above there are no other disadvantages.
There are no disadvantages for simple properties. The compiler creates the backing field for you. This blog entry explains how the compiler treats automatically implemented properties.
Not really a disadvantage, but you have to be aware of the default values of automatic properties. With "classic" properties we always used to initialize the backing fields, e.g. like this:
private bool _flag = true;
public bool Flag
{
get { return _flag; }
set { _flag = value; }
}
This made it obvious what the default value of the property is.
With automatic properties, you have to know what the default values are for the different types (e.g. false for bool). If you don't want the property to have the default value you have to initialize it in the constructor:
class MyClass
{
public bool Flag { get; set; }
public MyClass()
{
Flag = true;
}
}
This means, you have to implement a constructor if you want to initialize your properties to non default values or if a property is of a reference type (class).
But as I wrote, I do not really think of this as a disadvantage, just something you have to know.
The thing is, there is a corresponding field. You just don't see it because the compiler creates it for you. Automatic properties are just syntactic sugar or shorthand way to create the field.
No major things. Just edge cases like where you need to pass a property to a method where the parameter is passed by reference (ref or out) which isn't possible with a property (because internally, they're just get_Property/set_Property methods implemented by the compiler, not special fields of some kind) and you would need an explicit private backing field for this.
EDIT: Oh, and seconding the 'no readonly' properties, which is actually fairly common.
If you don't need to perform any specific logic in the get and/or set accessors, there's no disadvantage...
I say that they are bad from a code readability standpoint. Syntax sugar is nice for writing code but horrible for reading code. As developers the code we leave behind will ultimately be inherited by some poor developer that will have to make sense out of what we did and what is going on in the code. I really am against changing a language to simply save keystrokes when there is an established syntax for the same constructs.

Learning about Auto-Implemented Properties

I have the simple class using auto-implemented properies:
Public Class foo
{
public foo() { }
public string BarName {get; set;}
}
I obviously use the variable BarName throughout my class and now need to add logic when the property value is set (it must be all upper case, go figure). Does this mean that I need to now create a private variable for BarName , e.g. _BarName, and change the current BarName variable used throughout my class to _BarName?
Public Class foo
{
public foo() {}
private string _BarName = "";
public string BarName
{
get {return _BarName;}
set {_BarName = Value.ToString().ToUpper();}
}
}
I am trying to make sure I understand the implications of using auto-implemented properties, and what it will entail down the road when/if I need to change something. I am assuming that the refactoring, as shown above, is not a breaking change because the property is basically staying the same; it just took a little work inside the class to keep it that way and add the needed logic.
Another example, which may be more meaningful is that I need to call some method when a setter or getter is used; more then changing the value.
This seems a fair trade off the the lines and lines of code to setup properties.
Does this mean that I need to now
create a private variable for BarName
Yes
and change the current BarName
variable used throughout my class
Do not change the rest of the code in your class to use the new private variable you create. BarName, as a property, is intended to hide the private variable (among other things), for the purpose of avoiding the sweeping changes you contemplate to the rest of your code.
I am assuming that the refactoring, as
shown above, is not a breaking change
because the property is basically
staying the same; it just took a
little work to keep it that way and
add the needed logic.
Correct.
You don't need to change anything. Auto-implemented properties are just syntactic sugar. The compiler is generating the private variable and get/set logic for you, behind the scenes. If you add your own getter/setter logic the compiler will use your code instead of its auto-generated code, but as far as the users of that property are concerned, nothing has changed; any code referencing your property will continue to work.
When using automatic properties you don't get direct access to the underlying "backing" variable and you don't get access to the actual logic that gets implemented in the property getter and setter. You only have access to the property (hence using BarName throughout your code).
If you now need to implement specific logic in the setter, you can no longer use automatic properties and need to implement the property in the "old fashioned" way. In this case, you would need to implement your own private backing variable (the preferred method, at least for me, is to name the private backing variable the same name as the property, but with an initial lowercase (in this case, the backing variable would be named barName). You would then implement the appropriate logic in the getter/setter.
In your example, you are correct that it is not a breaking change. This type of refactoring (moving from automatic properties to "normal" properties should never be a breaking change as you aren't changing the public interface (the name or accessibility of the public property).
Don't use automatic properties if you know that you are going to validate that object. These objects can be domain objects etc. Like if you have a Customer class then use private variables because you might need to validate the name, birthdate etc. But if you are using a Rss class then it will be okay to just use the automatic properties since there is no validation being perform and the class is just used to hold some data.
You are correct about the refactoring and it really shouldn't break anything.
Whether or not you actually need to go through the references within the class to the property name and change those to refer to the private field would depend on whether the internal code needed to access the underlying representation of the data rather than how it was presented to consumers of the class. In most cases you could leave well enough alone.
In your simple example it would be wise to leave well enough alone and ensure that no code internal to the class could subvert the conversion/formatting being performed in the setter.
If on the other hand the getter was doing some magic to change the internal representation of the field into the way consumers needed to view the data then perhaps (in some cases) the internal code within the class would need to access the field.
You would need to look at each occurrence of the access to the auto-property in the class and decide whether it should be touching the field or using the property.
Automatic properties are just syntactic sugar, the compiler in fact creates the private member for it, but since it's generated at compile time, you cannot access it.
And later on, if you want to implement getters and setters for the property, only then you create a explicit private member for it and add the logic.

Categories