Common VB nomenclature

[SparkPlug]

I've noticed a nomenclature used by many VB developers of preceding variable
names by an underscore e.g. _instance.

Under what context is this usually used/not used.

Thanks.

[Kerry Moorman]

SparkPlug,

This naming convention is used by some VB programmers when naming the
private variable that "backs" a public property procedure. For example:

Private _Test1 As Single

Public Property Test1() As Single
Get
Return _Test1
End Get
Set(ByVal Value As Single)
If Value >= 0 And Value <= 100 Then
_Test1 = Value
Else
Throw New ApplicationException("Invalid Test1 value")
End If
End Set
End Property

Kerry Moorman

"SparkPlug" wrote:

I've noticed a nomenclature used by many VB developers of preceding variable
names by an underscore e.g. _instance.

Under what context is this usually used/not used.

Thanks.

[Jay B. Harlow [MVP - Outlook]]

SparkPlug,
As Kerry suggests it common to use _instance for instance fields.

Especially on Properties as you cannot have a Property named Instance & a
field called instance as you can in C#.

As a matter of consistency I generally prefix *all* fields m_ as I see no
value in identifying fields that back properties as opposed to other fields
that may be on a class. I simply see them as fields on a class...

--
Hope this helps
Jay B. Harlow [MVP - Outlook]
..NET Application Architect, Enthusiast, & Evangelist
T.S. Bradley - http://www.tsbradley.net
"SparkPlug" <Sp*******@discussions.microsoft.com> wrote in message
news:0D**********************************@microsof t.com...
| I've noticed a nomenclature used by many VB developers of preceding
variable
| names by an underscore e.g. _instance.
|
| Under what context is this usually used/not used.
|
| Thanks.

[Cor Ligthert [MVP]]

SparkPlug,

As any underscore in a program, I hate them. Some cursors hide those
underscore.

I use as I have seen more done for a private field accessed by a property a
single m as prefix.

And in my idea is that the only place that I need them.

Cor

"SparkPlug" <Sp*******@discussions.microsoft.com> schreef in bericht
news:0D**********************************@microsof t.com...

I've noticed a nomenclature used by many VB developers of preceding
variable
names by an underscore e.g. _instance.

Under what context is this usually used/not used.

Thanks.

[SparkPlug]

Thanks to all replies.

It is as I suspected so I was using it in that way but had never actually
been informed for certain.

[Herfried K. Wagner [MVP]]

"SparkPlug" <Sp*******@discussions.microsoft.com> schrieb:

I've noticed a nomenclature used by many VB developers of preceding
variable
names by an underscore e.g. _instance.

The naming guidelines do not have any information on how to name private
variables. However, some people use the '_' or 'm_' prefix to visually mark
them as private variables:

\\\
Private m_UserName As String

Public Property UserName() As String
Get
Return m_UserName
End Get
Set(ByVal Value As String)
m_UserName = Value
End Set
End Property
///

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

[SparkPlug]

"Jay B. Harlow [MVP - Outlook]" wrote:

As a matter of consistency I generally prefix *all* fields m_ as I see no
value in identifying fields that back properties as opposed to other fields
that may be on a class. I simply see them as fields on a class...

Just curious, where did the 'm' come from?
Thanks.

[Jay B. Harlow [MVP - Outlook]]

SparkPlug
| Just curious, where did the 'm' come from?
I learned it in C++ it stands for Member.

Some VB6 developers use it to stand for Module...

--
Hope this helps
Jay B. Harlow [MVP - Outlook]
..NET Application Architect, Enthusiast, & Evangelist
T.S. Bradley - http://www.tsbradley.net
"SparkPlug" <Sp*******@discussions.microsoft.com> wrote in message
news:FC**********************************@microsof t.com...
|
|
| "Jay B. Harlow [MVP - Outlook]" wrote:
| >
| > As a matter of consistency I generally prefix *all* fields m_ as I see
no
| > value in identifying fields that back properties as opposed to other
fields
| > that may be on a class. I simply see them as fields on a class...
|
| Just curious, where did the 'm' come from?
| Thanks.
|