Best Practices - Coding Convention Question

[Ren]

Hi All,

I'm still rather new at vb.net and would like to know the proper way to access
private varibables in a class. Do I access the variable directly or do I use
the public property?

public class MyClass
private _variableName as integer

public property VariableName as integer
get
return _variableName
end get
set(byVal Value as integer)
_variableName = value
end set
end property

public sub DoSomething ()
' do I use _variableName or
' do I use VariableName"
end sub

end class

Thanks

 

[Chris]

Hi All,

I'm still rather new at vb.net and would like to know the proper way to access
private varibables in a class. Do I access the variable directly or do I use
the public property?

public class MyClass
private _variableName as integer

public property VariableName as integer
get
return _variableName
end get
set(byVal Value as integer)
_variableName = value
end set
end property

public sub DoSomething ()
' do I use _variableName or
' do I use VariableName"
end sub

end class

Thanks

Not sure of best practice on this, but from a practice level, if you use
the property it allows you to make changes during the get/set in the
future w/o having to recode rest of the class.

Chris

 

[Cor Ligthert [MVP]]

Ren,

I use for the private variable
mVariableName

For the rest as you wrote with _variableName a notation that I hate.

By the way there is never a Best Practice. Luckily this is always a part of
discussion.

Typical for the VBNet developper is that he/she is human and can change when
it is needed and take the best Practice for that situation.

Cor

 

[Herfried K. Wagner [MVP]]

I'm still rather new at vb.net and would like to know the proper way to
access
private varibables in a class. Do I access the variable directly or do I
use
the public property?

I consider accessing it through the property's 'Get'/'Set' accessor even
inside the class whereever possible good practice, because it will prevent
assignment of invalid values to the property. Execution overhead is minimal
because the JIT compiler can inline property access.

 

[tommaso.gastaldi]

I agree with Cor and Herfried. There is no reason to treat the property
differently within its class. It can only be cause of errors. If you
feel you need it, it probably means you are doing something you should
not, or you are doing it the wrong way.

On the practical side the greatest advantage is that you just write
"me." and you have all the properties there readily available
(intellisense). It's a lot more convenient...

-tom

 

[Michel Posseth [MCP]]

Cor ,

I use for the private variable
mVariableName

For the rest as you wrote with _variableName a notation that I hate.

funny the parctical guidelines book states that m_VariableName should be
used

By the way there is never a Best Practice. Luckily this is always a part
of discussion.

Typical for the VBNet developper is that he/she is human and can change
when it is needed and take the best Practice for that situation.

Have you ever heard of programming by MSF ?? MSF holds a colection of
practical guidelines and best practices wich includes naming conventions
So these rules do exist ............. however do we want to implement them
as strict as they are,, that is more the question

If we would code by these rules our programs would be more readable and
understandable , however practice learns that most coders prefer there own
conventions ( you still see hungarion notation in .net code for
stance ) or even worse program without anny conventions at all ( 90 % of
the code i saw in my daily work was like this, and i have seen code from
all over the world by all sorts of programmers ) ...

So the guidelines do exist MS has verry nice documentation regarding this ,
however we , as programming comunity do not enforce them or expect them to
be the standard ... that is the problem in my opinion .

see for more info about MSF :

http://www.microsoft.com/technet/itsolutions/msf/default.mspx

personal recomendation regarding this :

Practical Guidelines and best practices for Microsoft Visual Basic and
visual C# Developers
http://www.amazon.com/gp/product/07...f=pd_bbs_1/102-6548994-9968922?_encoding=UTF8



Having said this i will start packing my suitcase as my plain leaves
tomorrow to the canary islands
i will have a 2 week holliday before i start my new job

regards

Michel Posseth [MCP]

 

[Lee]

Something not addressed in the other posts...

If you always reference the private variable by its property-name and
you need to search for where the property is referenced you only have
to search for one thing -- the property. Otherwise, within the class
wherein it's defined, you have to search for both the property-name and
the variable-name.

 

[Branco Medeiros]

Ren wrote:

I'm still rather new at vb.net and would like to know the proper way to access
private varibables in a class. Do I access the variable directly or do I use
the public property?

public class MyClass
private _variableName as integer

public property VariableName as integer

end property

public sub DoSomething ()
' do I use _variableName or
' do I use VariableName"
end sub

end class

Properties were created to protect, and even hide, the internal
structure of the object from the outside world. Ideally, only the
object itself should know about it's internal fields and how they
relate to the exposed properties.

Besides, properties allow for side-effects to happen when a given field
is accessed. Therefore, a property actually encapsulates a behavior.

Now, it's a very common practice to expose internal fields -- that were
suposed to be public -- through properties, even though these
properties are only getters/setters (I'm talking about just those
properties that are both a getter and a setter for a given field). The
reasoning is: a) you must not expose your internal fields and b)
properties protect you by keeping your interface intact should the
internal workings of the object change.

But It turns out that I see more frequent changes to an in-progress
object interface than to the internals of the object, usually because
of unantecipated needs of the "external world" (from the object's
perspective), even though the internal structure of the object remains
more or less intact.

Considering this, and as a left over from the time when compilers
wouldn't be smart enough to inline the access to properties, my
personal practice goes against (although not religiously) accessing
internal fields via getter/setter properties.

I mean, the object is in a priviledged position to see these fields, so
it should also exercise direct access to them.

Therefore, internally I'd use mVariableName, instead of the related
properties.

Regards,

Branco.

 

[Cor Ligthert [MVP]]

Michel,

Did you ever look at modern Visual Basic samples on MSDN (not from C++ -> C#
converted ones).

Microsoft has showed much of those patterns, it seems for me that it depends
who made it what it look like.

Cor

Cor ,

I use for the private variable
mVariableName

For the rest as you wrote with _variableName a notation that I hate.

funny the parctical guidelines book states that m_VariableName should be
used

By the way there is never a Best Practice. Luckily this is always a part
of discussion.

Typical for the VBNet developper is that he/she is human and can change
when it is needed and take the best Practice for that situation.

Have you ever heard of programming by MSF ?? MSF holds a colection of
practical guidelines and best practices wich includes naming conventions
So these rules do exist ............. however do we want to implement them
as strict as they are,, that is more the question

If we would code by these rules our programs would be more readable and
understandable , however practice learns that most coders prefer there own
conventions ( you still see hungarion notation in .net code for
ance ) or even worse program without anny conventions at all ( 90 % of
the code i saw in my daily work was like this, and i have seen code from
all over the world by all sorts of programmers ) ...

So the guidelines do exist MS has verry nice documentation regarding this
, however we , as programming comunity do not enforce them or expect them
to be the standard ... that is the problem in my opinion .

see for more info about MSF :

http://www.microsoft.com/technet/itsolutions/msf/default.mspx

personal recomendation regarding this :

Practical Guidelines and best practices for Microsoft Visual Basic and
visual C# Developers

http://www.amazon.com/gp/product/07...f=pd_bbs_1/102-6548994-9968922?_encoding=UTF8



Having said this i will start packing my suitcase as my plain leaves
tomorrow to the canary islands
i will have a 2 week holliday before i start my new job

regards

Michel Posseth [MCP]

Ren,

I use for the private variable
mVariableName

For the rest as you wrote with _variableName a notation that I hate.

By the way there is never a Best Practice. Luckily this is always a part
of discussion.

Typical for the VBNet developper is that he/she is human and can change
when it is needed and take the best Practice for that situation.

Cor

 

[Carlos J. Quintero [VB MVP]]

Hi Ren,

It depends on the case. In your example there is no difference, but there
are cases where the Get/Set accessors execute additional code (validation,
caching, etc) and in those cases you need to consider if you want that
additional code to be executed or not.

--

Best regards,

Carlos J. Quintero

MZ-Tools: Productivity add-ins for Visual Studio
You can code, design and document much faster:
http://www.mztools.com

 

[Herfried K. Wagner [MVP]]

Besides, properties allow for side-effects to happen when a given field
is accessed. Therefore, a property actually encapsulates a behavior.

Now, it's a very common practice to expose internal fields -- that were
suposed to be public -- through properties, even though these
properties are only getters/setters (I'm talking about just those
properties that are both a getter and a setter for a given field). The
reasoning is: a) you must not expose your internal fields and b)
properties protect you by keeping your interface intact should the
internal workings of the object change.

But It turns out that I see more frequent changes to an in-progress
object interface than to the internals of the object, usually because
of unantecipated needs of the "external world" (from the object's
perspective), even though the internal structure of the object remains
more or less intact.

Considering this, and as a left over from the time when compilers
wouldn't be smart enough to inline the access to properties, my
personal practice goes against (although not religiously) accessing
internal fields via getter/setter properties.

I mean, the object is in a priviledged position to see these fields, so
it should also exercise direct access to them.

Consider this sample:

\\\
Private m_Bla As Integer

Public Property Bla() As Integer
Get
Return m_Bla
End Get
Set(...)
If Value < 0 OrElse Value > 10 Then
Throw New ArgumentException(...)
Else
m_Bla = Value
End If
End Set
End Property
///

When assigning the value to 'm_Bla' directly you are bypassing validation
and it's possible that the property value returned by 'Get' is an invalid
value due to bugs in the code which cause an invalid value to be assigned to
the private backing field. I strongly believe that it's better to have only
a single code path to access 'm_Bla' than multiple paths.