5 Improved question
source | link

Before I started using auto-implemented properties, I was taught that when assigning properties in the constructor (because of the potential of making a property read only), I should assign directly to the private member for the property (which we would usually name with the property's name with an underscore in front of it. EX: _propertyName.)

When I switched to using auto-implemented properties, I kept the practice, even so much as establishing that only the private members should be referenced inside the property's class. I understand those auto-implemented, private members are referred to as "Backing Fields".

Considering the usefulness of backing fields, I find it fascinating that they are invisible to intellisense until fully typed. Furthermore, I made the observation that when you auto-implement the property, it appears as though you can assign to a Read Only property within the property's class.

Considering the changes that have happened in the .net framework, I am beginning to question what is the "Right" way to handle properties from within the class. I understand that is somewhat subjective, but I wonder, are there drawbacks to the way I have done this? So I'm left with a couplefew questions on how this works, and what the implications on my software's design (however minor) are:

  1. Does calling the auto-implemented property from within property's class call the Get and Set (even when set to "read only")?
  2. Does calling the property's backing field bypass this?
  3. Am I wasting (however few) processor cycles by using the the property instead of the backing field?
  4. Or am I exposing myself to a potential problem in the future by using the backing fields?

Or broader question:

What is difference between assigning to auto-Implemented properties VS assigning directly to their backing fields?

UPDATE

I now understand my question is more applicable to vb.net, as you cannot access auto-implemented Backing Fields in C#. And if you wanted to assign directly to a backing field in C#, you cannot use the auto-implement.

So the broader question and the question of practice is still applicable to either language.

UPDATE TO TRY SCARE UP A NARROWED ANSWER FOR VB

So I've gotten a lot of helpful feedback, but in all the answers none have directly addressed all 4 specific questions (perhaps because they initially seem irrelevant) but in my situation, I'm assigning to the backing fields of Auto-Implemented properties. This means that it does not bypass any critical, breaking code (as the auto-implemented, hidden Get and Set have no logic in them).

Bearing in mind that backing fields are Private and that you would only be able to assign to the backing field of a property that you personally wrote as auto-implemented (as you wrote the class), here's another way to sum up some of my questions above:

What is the issue with directly assigning to the backing field of an auto-implemented property?

Thanks!

Before I started using auto-implemented properties, I was taught that when assigning properties in the constructor (because of the potential of making a property read only), I should assign directly to the private member for the property (which we would usually name with the property's name with an underscore in front of it. EX: _propertyName.)

When I switched to using auto-implemented properties, I kept the practice, even so much as establishing that only the private members should be referenced inside the property's class. I understand those auto-implemented, private members are referred to as "Backing Fields".

Considering the usefulness of backing fields, I find it fascinating that they are invisible to intellisense until fully typed. Furthermore, I made the observation that when you auto-implement the property, it appears as though you can assign to a Read Only property within the property's class.

Considering the changes that have happened in the .net framework, I am beginning to question what is the "Right" way to handle properties from within the class. I understand that is somewhat subjective, but I wonder, are there drawbacks to the way I have done this? So I'm left with a couple questions on how this works, and what the implications on my software's design (however minor) are:

  1. Does calling the auto-implemented property from within property's class call the Get and Set (even when set to "read only")?
  2. Does calling the property's backing field bypass this?
  3. Am I wasting (however few) processor cycles by using the the property instead of the backing field?
  4. Or am I exposing myself to a potential problem in the future by using the backing fields?

Or broader question:

What is difference between assigning to auto-Implemented properties VS assigning directly to their backing fields?

UPDATE

I now understand my question is more applicable to vb.net, as you cannot access auto-implemented Backing Fields in C#. And if you wanted to assign directly to a backing field in C#, you cannot use the auto-implement.

So the broader question and the question of practice is still applicable to either language.

Thanks!

Before I started using auto-implemented properties, I was taught that when assigning properties in the constructor (because of the potential of making a property read only), I should assign directly to the private member for the property (which we would usually name with the property's name with an underscore in front of it. EX: _propertyName.)

When I switched to using auto-implemented properties, I kept the practice, even so much as establishing that only the private members should be referenced inside the property's class. I understand those auto-implemented, private members are referred to as "Backing Fields".

Considering the usefulness of backing fields, I find it fascinating that they are invisible to intellisense until fully typed. Furthermore, I made the observation that when you auto-implement the property, it appears as though you can assign to a Read Only property within the property's class.

Considering the changes that have happened in the .net framework, I am beginning to question what is the "Right" way to handle properties from within the class. I understand that is somewhat subjective, but I wonder, are there drawbacks to the way I have done this? So I'm left with a few questions on how this works, and what the implications on my software's design (however minor) are:

  1. Does calling the auto-implemented property from within property's class call the Get and Set (even when set to "read only")?
  2. Does calling the property's backing field bypass this?
  3. Am I wasting (however few) processor cycles by using the the property instead of the backing field?
  4. Or am I exposing myself to a potential problem in the future by using the backing fields?

Or broader question:

What is difference between assigning to auto-Implemented properties VS assigning directly to their backing fields?

UPDATE

I now understand my question is more applicable to vb.net, as you cannot access auto-implemented Backing Fields in C#. And if you wanted to assign directly to a backing field in C#, you cannot use the auto-implement.

So the broader question and the question of practice is still applicable to either language.

UPDATE TO TRY SCARE UP A NARROWED ANSWER FOR VB

So I've gotten a lot of helpful feedback, but in all the answers none have directly addressed all 4 specific questions (perhaps because they initially seem irrelevant) but in my situation, I'm assigning to the backing fields of Auto-Implemented properties. This means that it does not bypass any critical, breaking code (as the auto-implemented, hidden Get and Set have no logic in them).

Bearing in mind that backing fields are Private and that you would only be able to assign to the backing field of a property that you personally wrote as auto-implemented (as you wrote the class), here's another way to sum up some of my questions above:

What is the issue with directly assigning to the backing field of an auto-implemented property?

Thanks!

4 Fixed some grammar
source | link

Before I started using auto-implemented properties, I was taught that when assigning properties in the constructor (because of the potential of making a property read only), I should assign directly to the private member for the property (which we would usually name with the property's name with an underscore in front of it. EX: _propertyName.)

When I switched to using auto-implemented properties, I kept the practice, even so much as establishing that only the private members should be referenced inside the property's class. I understand those auto-implemented, private members are referred to as "Backing Fields".

Considering the usefulness of the backing fields, I find it fascinating that they are invisible to intellisense until fully typed. FurtherFurthermore, I made the observation that when you auto-implement the property, it appears as though you can assign to a Read Only property within the property's class.

Considering the changes that have happened in the .net framework, I am beginning to question what is the "Right" way to handle properties from within the class. I understand that is somewhat subjective, but I wonder, are there drawbacks to the way I have done this? So I'm left with a couple questions on how this works, and what the implications on my software's design (however minor) are:

  1. Does calling the auto-implemented property from within property's class call the Get and Set (even when set to "read only")?
  2. Does calling the property's backing field bypass this?
  3. Am I wasting (however few) processor cycles by using the the property instead of the backing field?
  4. Or am I exposing myself to a potential problem in the future by using the backing fields?

Or broader question:

What is difference between assigning to auto-Implemented properties VS assigning directly to their backing fields?

UPDATE

I now understand my question is more applicable to vb.net, as you cannot access auto-implemented Backing Fields in C#. And if you wanted to assign directly to a backing fieldsfield in C#, you cannot use the auto-implement.

So the broader question and the question of practice is still applicable to either language.

Thanks!

Before I started using auto-implemented properties, I was taught that when assigning properties in the constructor (because of the potential of making a property read only), I should assign directly to the private member for the property (which we would usually name with the property's name with an underscore in front of it. EX: _propertyName.)

When I switched to using auto-implemented properties, I kept the practice, even so much as establishing that only the private members should be referenced inside the property's class. I understand those auto-implemented, private members are referred to as "Backing Fields".

Considering the usefulness of the backing fields, I find it fascinating that they are invisible to intellisense until fully typed. Further, I made the observation that when you auto-implement the property, it appears as though you can assign to a Read Only property within the property's class.

Considering the changes that have happened in the .net framework, I am beginning to question what is the "Right" way to handle properties from within the class. I understand that is somewhat subjective, but I wonder, are there drawbacks to the way I have done this? So I'm left with a couple questions on how this works, and what the implications on my software's design (however minor) are:

  1. Does calling the auto-implemented property from within property's class call the Get and Set (even when set to "read only")?
  2. Does calling the property's backing field bypass this?
  3. Am I wasting (however few) processor cycles by using the the property instead of the backing field?
  4. Or am I exposing myself to a potential problem in the future by using the backing fields?

Or broader question:

What is difference between assigning to auto-Implemented properties VS assigning directly to their backing fields?

UPDATE

I now understand my question is more applicable to vb.net, as you cannot access auto-implemented Backing Fields in C#. And if you wanted to assign directly to a backing fields in C#, you cannot use the auto-implement.

So the broader question and the question of practice is still applicable to either language.

Thanks!

Before I started using auto-implemented properties, I was taught that when assigning properties in the constructor (because of the potential of making a property read only), I should assign directly to the private member for the property (which we would usually name with the property's name with an underscore in front of it. EX: _propertyName.)

When I switched to using auto-implemented properties, I kept the practice, even so much as establishing that only the private members should be referenced inside the property's class. I understand those auto-implemented, private members are referred to as "Backing Fields".

Considering the usefulness of backing fields, I find it fascinating that they are invisible to intellisense until fully typed. Furthermore, I made the observation that when you auto-implement the property, it appears as though you can assign to a Read Only property within the property's class.

Considering the changes that have happened in the .net framework, I am beginning to question what is the "Right" way to handle properties from within the class. I understand that is somewhat subjective, but I wonder, are there drawbacks to the way I have done this? So I'm left with a couple questions on how this works, and what the implications on my software's design (however minor) are:

  1. Does calling the auto-implemented property from within property's class call the Get and Set (even when set to "read only")?
  2. Does calling the property's backing field bypass this?
  3. Am I wasting (however few) processor cycles by using the the property instead of the backing field?
  4. Or am I exposing myself to a potential problem in the future by using the backing fields?

Or broader question:

What is difference between assigning to auto-Implemented properties VS assigning directly to their backing fields?

UPDATE

I now understand my question is more applicable to vb.net, as you cannot access auto-implemented Backing Fields in C#. And if you wanted to assign directly to a backing field in C#, you cannot use the auto-implement.

So the broader question and the question of practice is still applicable to either language.

Thanks!

3 Updated question with further detail and better understanding.
source | link

Before I started using auto-implemented properties, I was taught that when assigning properties in the constructor (because of the potential of making a property read only), I should assign directly to the private member for the property (which we would usually name with the property's name with an underscore in front of it. EX: _propertyName.)

When I switched to using auto-implemented properties, I kept the practice, even so much as establishing that only the private members should be referenced inside the property's class. I understand those auto-implemented, private members are referred to as "Backing Fields".

Considering the usefulness of the backing fields, I find it fascinating that they are invisible to intellisense until fully typed. Further, I made the observation that when you auto-implement the property, it appears as though you can assign to a Read Only property within the property's class.

Considering the changes that have happened in the .net framework, I am beginning to question what is the "Right" way to handle properties from within the class. I understand that is somewhat subjective, but I wonder, are there drawbacks to the way I have done this? So I'm left with a couple questions on how this works, and what the implications on my software's design (however minor) are:

  1. Does calling the auto-implemented property from within property's class call the Get and Set (even when set to "read only")?
  2. Does calling the property's backing field bypass this?
  3. Am I wasting (however few) processor cycles by using the the property instead of the backing field?
  4. Or am I exposing myself to a potential problem in the future by using the backing fields?

Or broader question:

What is difference between assigning to auto-Implemented properties VS assigning directly to their backing fields?

It seems thisUPDATE

I now understand my question almost straddles Software Engineering and Stack Overflow depending on howis more applicable to vb.net, as you word itcannot access auto-implemented Backing Fields in C#. Please let me knowAnd if I should modifyyou wanted to assign directly to a backing fields in C#, you cannot use the wording or migrate itauto-implement.

So the broader question and the question of practice is still applicable to either language.

Thanks!

Before I started using auto-implemented properties, I was taught that when assigning properties in the constructor (because of the potential of making a property read only), I should assign directly to the private member for the property (which we would usually name with the property's name with an underscore in front of it. EX: _propertyName.)

When I switched to using auto-implemented properties, I kept the practice, even so much as establishing that only the private members should be referenced inside the property's class. I understand those auto-implemented, private members are referred to as "Backing Fields".

Considering the usefulness of the backing fields, I find it fascinating that they are invisible to intellisense until fully typed. Further, I made the observation that when you auto-implement the property, it appears as though you can assign to a Read Only property within the property's class.

Considering the changes that have happened in the .net framework, I am beginning to question what is the "Right" way to handle properties from within the class. I understand that is somewhat subjective, but I wonder, are there drawbacks to the way I have done this? So I'm left with a couple questions on how this works, and what the implications on my software's design (however minor) are:

  1. Does calling the auto-implemented property from within property's class call the Get and Set (even when set to "read only")?
  2. Does calling the property's backing field bypass this?
  3. Am I wasting (however few) processor cycles by using the the property instead of the backing field?
  4. Or am I exposing myself to a potential problem in the future by using the backing fields?

Or broader question:

What is difference between assigning to auto-Implemented properties VS assigning directly to their backing fields?

It seems this question almost straddles Software Engineering and Stack Overflow depending on how you word it. Please let me know if I should modify the wording or migrate it.

Thanks!

Before I started using auto-implemented properties, I was taught that when assigning properties in the constructor (because of the potential of making a property read only), I should assign directly to the private member for the property (which we would usually name with the property's name with an underscore in front of it. EX: _propertyName.)

When I switched to using auto-implemented properties, I kept the practice, even so much as establishing that only the private members should be referenced inside the property's class. I understand those auto-implemented, private members are referred to as "Backing Fields".

Considering the usefulness of the backing fields, I find it fascinating that they are invisible to intellisense until fully typed. Further, I made the observation that when you auto-implement the property, it appears as though you can assign to a Read Only property within the property's class.

Considering the changes that have happened in the .net framework, I am beginning to question what is the "Right" way to handle properties from within the class. I understand that is somewhat subjective, but I wonder, are there drawbacks to the way I have done this? So I'm left with a couple questions on how this works, and what the implications on my software's design (however minor) are:

  1. Does calling the auto-implemented property from within property's class call the Get and Set (even when set to "read only")?
  2. Does calling the property's backing field bypass this?
  3. Am I wasting (however few) processor cycles by using the the property instead of the backing field?
  4. Or am I exposing myself to a potential problem in the future by using the backing fields?

Or broader question:

What is difference between assigning to auto-Implemented properties VS assigning directly to their backing fields?

UPDATE

I now understand my question is more applicable to vb.net, as you cannot access auto-implemented Backing Fields in C#. And if you wanted to assign directly to a backing fields in C#, you cannot use the auto-implement.

So the broader question and the question of practice is still applicable to either language.

Thanks!

2 fixed grammar and added some clarification
source | link
1
source | link