Skip to content
  • Categories
  • Recent
  • Tags
  • Popular
  • World
  • Users
  • Groups
Skins
  • Light
  • Cerulean
  • Cosmo
  • Flatly
  • Journal
  • Litera
  • Lumen
  • Lux
  • Materia
  • Minty
  • Morph
  • Pulse
  • Sandstone
  • Simplex
  • Sketchy
  • Spacelab
  • United
  • Yeti
  • Zephyr
  • Dark
  • Cyborg
  • Darkly
  • Quartz
  • Slate
  • Solar
  • Superhero
  • Vapor

  • Default (No Skin)
  • No Skin
Collapse
Code Project
  1. Home
  2. General Programming
  3. Visual Basic
  4. VB and .Net Naming Guidelines

VB and .Net Naming Guidelines

Scheduled Pinned Locked Moved Visual Basic
csharpsalestutorialquestion
3 Posts 2 Posters 2 Views 1 Watching
  • Oldest to Newest
  • Newest to Oldest
  • Most Votes
Reply
  • Reply as topic
Log in to reply
This topic has been deleted. Only users with topic management privileges can see it.
  • K Offline
    K Offline
    Kevin McFarlane
    wrote on last edited by
    #1

    Hi, The .Net naming guidelines cannot be fully applied to Visual Basic. You can almost do it because, despite VB's case insensitivity, variable/method/property names and type names are in different namespaces and so do not clash. I don't think this was the case in VB6. For example, in VB .Net you can do: Dim customer As Customer and the compiler understands that customer is different from Customer. But for properties you run into trouble Private name Public Property Name() As String Get Return name End Get End Property name and Name clash so you end up having to do Private m_name or something. If the compiler could distinguish between variables and methods then the .Net conventions could be applied consistently for both VB and C#. With C#, I've been trying to follow the new guidelines but I'm still using Hungarian prefixes for controls. Microsoft don't say what to do for controls but I guess we should use full suffixes, i.e., customerText customerLabel customerCombo etc. Comments anyone? Kevin

    D 1 Reply Last reply
    0
    • K Kevin McFarlane

      Hi, The .Net naming guidelines cannot be fully applied to Visual Basic. You can almost do it because, despite VB's case insensitivity, variable/method/property names and type names are in different namespaces and so do not clash. I don't think this was the case in VB6. For example, in VB .Net you can do: Dim customer As Customer and the compiler understands that customer is different from Customer. But for properties you run into trouble Private name Public Property Name() As String Get Return name End Get End Property name and Name clash so you end up having to do Private m_name or something. If the compiler could distinguish between variables and methods then the .Net conventions could be applied consistently for both VB and C#. With C#, I've been trying to follow the new guidelines but I'm still using Hungarian prefixes for controls. Microsoft don't say what to do for controls but I guess we should use full suffixes, i.e., customerText customerLabel customerCombo etc. Comments anyone? Kevin

      D Offline
      D Offline
      David Wengier
      wrote on last edited by
      #2

      Where are these naming guidelines? I use m_iCount or miCount for member variables, iCount for local variables and Count for property names, and I dont have any problems. -- David Wengier TAC ad gone wrong: "Don't fool yourself, you're a bloody idiot." Sonork ID: 100.14177 - Ch00k

      K 1 Reply Last reply
      0
      • D David Wengier

        Where are these naming guidelines? I use m_iCount or miCount for member variables, iCount for local variables and Count for property names, and I dont have any problems. -- David Wengier TAC ad gone wrong: "Don't fool yourself, you're a bloody idiot." Sonork ID: 100.14177 - Ch00k

        K Offline
        K Offline
        Kevin McFarlane
        wrote on last edited by
        #3

        http://msdn.microsoft.com/library/default.asp?url=/library/en-us/cpgenref/html/cpconnetframeworkdesignguidelines.asp Hungarian notation is not recommended in the the new guidelines. However, you cannot apply these guidleines consistently to VB .NET. Though some are now suggesting that you can use what you like for private fields and locals. So for the Property problem in VB you can use m_iCount or m_count, etc. Kevin

        1 Reply Last reply
        0
        Reply
        • Reply as topic
        Log in to reply
        • Oldest to Newest
        • Newest to Oldest
        • Most Votes


        • Login

        • Don't have an account? Register

        • Login or register to search.
        • First post
          Last post
        0
        • Categories
        • Recent
        • Tags
        • Popular
        • World
        • Users
        • Groups