Access member variable directly or through property within the class it is defined?

(Slightly religious question):

Suppose I have the following class:

---snip---
Public Class MyClass
Private _MyVariable As Integer

Public Property MyVariable() As Integer
Get
Return Me._MyVariable
End Get
Set(ByVal value As Integer)
'(some value checking going on here)
Me._MyVariable = value
End Set
End Property

Private Sub MyMethod1
_MyVariable = 0
End Sub

Private Sub MyMethod2
MyVariable = 0
End Sub

End Class
---snip---

Is there a recommended best practice (class library design
guidelines?) for accessing _MyVariable?

MyMethod1 takes the direct route, thereby bypassing any
value checking and side effects in the property setter.

MyMethod2 goes through the property setter, which has
the benefit of value checking/side effects, but might be
overkill considering the performance hit incurred by the
extra function call, especially if the values assigned are
known to be valid.

Still, if the priority is *maintainability*, wouldn't it be best only
to use the direct access in the constructor only and the
property setter in all other cases? To avoid multiple side
effects as a result of setting multiple properties at once
(e.g. if the class is a graphical control), would the best
practice be to disable all updates, set multiple properties,
then enable updates again, in order to use property setters
all the time internally?

What do you do?

/JB

IMHO, I think it's perfectly fine for a Class to "internally" set its
private variables without going through their Accessors. The class (you as
the developer) should know when this makes sense and when it doesn't. For
instance, when you want PropertyChanged events to be raised with
databound-aware classes (yes, even regular ol' classes support this) then
you'll probably want to change properties via their Accessors.

It should be noted that there is practically 0% performance impact by going
through the Accessors.... however, for the situations where Property
Accessors actually do WORK, then for the sake of consistency and
maintainability (and maybe performance)... sometimes implementing a
WindowsForms-like 'SuspendLayout' - Modify Lots of Properties -
'ResumeLayout' is nice and elegant even INSIDE the class. This is
situation-specific and definately not a "rule."

In short... it's up to you.

P.S. Now, whether you should be using PascalCase and underscores for private
variables is a totally different matter. That IS a religious question. ;-)

P.P.S. When accessing *Properties Accessors* internally it helps
maintainability to do so using "Me." This is a fairly common coding standard
(unfortunately not so much in the VB world). The rule doesn't really apply
to the variables themselves or to Methods... just Properties. If you use
this practice for awhile, you'll see why it makes sense.

--
-C. Moya
www.cmoya.com
"Joergen Bech @ post1.tele.dk>" <jbech<NOSPAMNOSPAM> wrote in message
news:vo7ov11t193suj30s0s7rhef9tuiohmurb@4ax.com...
>
> (Slightly religious question):
>
> Suppose I have the following class:
>
> ---snip---
> Public Class MyClass
> Private _MyVariable As Integer
>
> Public Property MyVariable() As Integer
> Get
> Return Me._MyVariable
> End Get
> Set(ByVal value As Integer)
> '(some value checking going on here)
> Me._MyVariable = value
> End Set
> End Property
>
> Private Sub MyMethod1
> _MyVariable = 0
> End Sub
>
> Private Sub MyMethod2
> MyVariable = 0
> End Sub
>
> End Class
> ---snip---
>
> Is there a recommended best practice (class library design
> guidelines?) for accessing _MyVariable?
>
> MyMethod1 takes the direct route, thereby bypassing any
> value checking and side effects in the property setter.
>
> MyMethod2 goes through the property setter, which has
> the benefit of value checking/side effects, but might be
> overkill considering the performance hit incurred by the
> extra function call, especially if the values assigned are
> known to be valid.
>
> Still, if the priority is *maintainability*, wouldn't it be best only
> to use the direct access in the constructor only and the
> property setter in all other cases? To avoid multiple side
> effects as a result of setting multiple properties at once
> (e.g. if the class is a graphical control), would the best
> practice be to disable all updates, set multiple properties,
> then enable updates again, in order to use property setters
> all the time internally?
>
> What do you do?
>
> /JB
>
>
>

Joergen,

Maybe can the only problem be that you come in trouble in version 2005
because the start with an underscore for a variable is not always CLS
compliant.

See a long current thread in this newsgroup from someone who was in trouble
with that. I have only touched it slightly.

In fact are your methods 1 and 2 without sense. And therefore I would
absolute not implement them at all.

Cor

"Joergen Bech @ post1.tele.dk>" <jbech<NOSPAMNOSPAM> schrieb:
> ---snip---
> Public Class MyClass
> Private _MyVariable As Integer
>
> Public Property MyVariable() As Integer
> Get
> Return Me._MyVariable
> End Get
> Set(ByVal value As Integer)
> '(some value checking going on here)
> Me._MyVariable = value
> End Set
> End Property
>
> Private Sub MyMethod1
> _MyVariable = 0
> End Sub
>
> Private Sub MyMethod2
> MyVariable = 0
> End Sub
>
> End Class
> ---snip---
>
> Is there a recommended best practice (class library design
> guidelines?) for accessing _MyVariable?

I do not know if there is a recommendation, but I recomment to call the
accessor instead of accessing the private variable even in the class. The
advantage of doing that is that validation code gets executed and that it's
guaranteed that the private variable never holds an invalid value. This
prevents errors from occuring in algorithms and methods relying on the
property's value. By accessing the property duplicated range-checking code
can be removed and put into the property's 'Set' part only.

The runtime overhead for accessing the property instead of the variable
should be minimal given the JITter could inline the property access in some
cases.

> Still, if the priority is *maintainability*, wouldn't it be best only
> to use the direct access in the constructor only and the
> property setter in all other cases?

I /always/ set the property value through the property.

--
M S Herfried K. Wagner
M V P <URL:http://dotnet.mvps.org/>
V B <URL:http://classicvb.org/petition/>

"Cor Ligthert [MVP]" <notmyfirstname@planet.nl> schrieb:
> Maybe can the only problem be that you come in trouble in version 2005
> because the start with an underscore for a variable is not always CLS
> compliant.
>
> See a long current thread in this newsgroup from someone who was in
> trouble with that. I have only touched it slightly.

Well, but this does not apply to private variables.

--
M S Herfried K. Wagner
M V P <URL:http://dotnet.mvps.org/>
V B <URL:http://classicvb.org/petition/>

Underscores or no underscores and whether the methods
are useful for anything is besides the point. I am aware that
I need to re-read some guidelines for coding style. Some other
time.

The question was about best practices for accessing member
variables. The sample was written as concisely as possible to
illustrate the differences.

/JB

On Wed, 22 Feb 2006 11:14:51 +0100, "Cor Ligthert [MVP]"
<notmyfirstname@planet.nl> wrote:

>Joergen,
>
>Maybe can the only problem be that you come in trouble in version 2005
>because the start with an underscore for a variable is not always CLS
>compliant.
>
>See a long current thread in this newsgroup from someone who was in trouble
>with that. I have only touched it slightly.
>
>In fact are your methods 1 and 2 without sense. And therefore I would
>absolute not implement them at all.
>
>Cor
>

>> Still, if the priority is *maintainability*, wouldn't it be best only
>> to use the direct access in the constructor only and the
>> property setter in all other cases?
>
>I /always/ set the property value through the property.

The constructor is *the* one place where I normally would want
to initialize all the members directly, without any checks or
side effects, but come to think of it ... good point you made there.

/JB

>> Maybe can the only problem be that you come in trouble in version 2005
>> because the start with an underscore for a variable is not always CLS
>> compliant.
>>
>> See a long current thread in this newsgroup from someone who was in
>> trouble with that. I have only touched it slightly.
>
> Well, but this does not apply to private variables.
>
> --

So I wrote it correct?

:-)

Cor

I don't think there's much controversy in any development community
concerning this. The only general rule is that Accessors (C++ terminology)
must be used by other classes. Inside the class, you're free to do as you
wish... as long as its consistent. I agree with the others here that it's
"good" if you use the Accessors internally.....

..... though I myself don't care much for it. I use it only when it makes
sense to do so. Consistency is the Golden Rule. If you decide to *mainly*
access the variables directly, then only use the Accessors when you want to
trigger whatever work they do (validation, etc). If you decide to *mainly*
use Accessors, then only use the member variables for a darn good reason.
That way it becomes instantly clear to anyone maintaining your code what
your intentions were in a particular line of code.... "oh I see, he's
accessing the variable on purpose to sidestep the validation in this special
case."

P.S. Yes, I know this is slightly OT... but, one thing I would stress again
is using Me (for Properties). This is a pretty strict standard in the
development world (even though not many of us VB folks practice it... to
our detriment).

--
-C. Moya
www.cmoya.com

"Joergen Bech @ post1.tele.dk>" <jbech<NOSPAMNOSPAM> wrote in message
news:2gfov198dfdnl4o7ll6ht4mhctc7n25sop@4ax.com...
>
>>> Still, if the priority is *maintainability*, wouldn't it be best only
>>> to use the direct access in the constructor only and the
>>> property setter in all other cases?
>>
>>I /always/ set the property value through the property.
>
> The constructor is *the* one place where I normally would want
> to initialize all the members directly, without any checks or
> side effects, but come to think of it ... good point you made there.
>
> /JB
>
>
>

>.... though I myself don't care much for it. I use it only when it makes
>sense to do so. Consistency is the Golden Rule. If you decide to *mainly*

Yes, Consistency is the key word, and since I am just starting a major
new project, I was looking for some "official" guidelines, e.g. FxCop,
Design Guidelines for Class Library Developers, SSW rules
(http://ssw.com.au/SSW/Standards/Default.aspx),
and yes, general recommendations from this group (or links to more
guidelines).

>P.S. Yes, I know this is slightly OT... but, one thing I would stress again
>is using Me (for Properties). This is a pretty strict standard in the
>development world (even though not many of us VB folks practice it... to
>our detriment).

The examples in Microsoft's own guidelines document use

m_myVariable

i.e. camel Casing for fields, and accessed without the Me
keyword (I am talking about the VB examples), but the framework
itself just uses camel Casing, without the m_ prefix.

So yes I agree, choose and stick with the choice.

I suppose prefixing the private fields with "m_" is the best approach:
If this is used consistently, there is never any doubt whether the
field is accessed directly or through the accessor. I like the prefix
approach (whether it is "_" or "m_") as it allows me to use the "same"
name for the field as well as the accessor. Visually, using "Me." is
a good argument if just using the "_" prefix, but might be overkill
if using the "m_" prefix(?) Hm ... I cannot use the same
name and let the scope rules determine what is what, i.e. look
at CheckBox.CheckState in the framework:

Private checkState As CheckState
Public Property CheckState As CheckState
Get
Return Me.checkState
End Get
...
End Property

Such code is for C#-programmers with their case-sensitivity.

....

Actually ... re-reading the Microsoft guidelines, they talk a lot
about how the classes should look externally, but no naming
conventions (that I can find) for private fields. Some examples
use the "m_" prefix, others postfix their fields with "Value"
(e.g. xValue for a property named X).

Only consistent thing is the use of camel Casing.

So I guess I am down to "Me._myVariable" or "m_myVariable".

/JB