All though you could do that, imagine working with this API and seeing that you have object.Name
and object.name
. How would you know which one to use?
Generally, public fields are considered bad practice, because you're giving the user of that class full power to field. Even though an auto property gives the same amount of power, it makes it easier to add calculations/filters to the setter or getter, or remove a setter or getter altogether.
By making the backing field public, you are giving the user the power to completely ignore anything validation you had set up.
I think you might be getting confused here.
As you can see in this sharplab.io example,
public string Name { get; set; }
Compiles into:
private string <Name>k__BackingField;
public string Name
{
get { return this.<Name>k__BackingField; }
set { this.<Name>k__BackingField = value; }
}
So you can see, the actual field exists, however its inaccessible to everyone, so its like super-private. Sometimes you may not want this, however. I've ran into a few times where I actually wanted the class of the property to be able to access the private backing field to avoid calling the set and gets, to avoid infinite loops, though I feel this can be a bad practice, and should be avoided.
But point being, auto properties do have a private field behind the scenes and are not a private field unto themselves.