Common VB nomenclature

Collapse
This topic is closed.
X
X
 
  • Time
  • Show
Clear All
new posts
  • SparkPlug

    #1

    Common VB nomenclature

    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

    #2
    RE: Common VB nomenclature

    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 ApplicationExce ption("Invalid Test1 value")
    End If
    End Set
    End Property

    Kerry Moorman



    "SparkPlug" wrote:
    [color=blue]
    > 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.[/color]

    Comment

    • Jay B. Harlow [MVP - Outlook]

      #3
      Re: Common VB nomenclature

      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" <SparkPlug@disc ussions.microso ft.com> wrote in message
      news:0DE9E1D5-E241-485C-A8A0-F24EF5E885D9@mi crosoft.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.


      Comment

      • Cor Ligthert [MVP]

        #4
        Re: Common VB nomenclature

        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" <SparkPlug@disc ussions.microso ft.com> schreef in bericht
        news:0DE9E1D5-E241-485C-A8A0-F24EF5E885D9@mi crosoft.com...[color=blue]
        > 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.[/color]


        Comment

        • SparkPlug

          #5
          RE: Common VB nomenclature

          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.

          Comment

          • Herfried K. Wagner [MVP]

            #6
            Re: Common VB nomenclature

            "SparkPlug" <SparkPlug@disc ussions.microso ft.com> schrieb:[color=blue]
            > I've noticed a nomenclature used by many VB developers of preceding
            > variable
            > names by an underscore e.g. _instance.[/color]


            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/>

            Comment

            • SparkPlug

              #7
              Re: Common VB nomenclature



              "Jay B. Harlow [MVP - Outlook]" wrote:[color=blue]
              >
              > 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...[/color]

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

              Comment

              • Jay B. Harlow [MVP - Outlook]

                #8
                Re: Common VB nomenclature

                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" <SparkPlug@disc ussions.microso ft.com> wrote in message
                news:FCD1CD14-8807-4B7A-89DA-B49AC0CF3104@mi crosoft.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.
                |


                Comment

                Working...