I am generally not one to engage in subjective arguments over matters like variable naming, code formatting, etc. So I have no intention of starting an argument here.

I just came across this (old) blog post which recommends not prefixing member variable names:

Do not use a prefix for member variables (_, m_, s_, etc.). If you want to distinguish between local and member variables you should use "this." in C# and "Me." in VB.NET.

For C#, yeah, I get it: member variables can be lower camelCase, and public properties/methods can be PascalCase. But VB.NET is case-insensitive, so you can't really give a private member the same name as a public property except with a lower case first letter.

I've generally prefixed member variables with an underscore, but I've been told that's not idiomatic.

So really I'm just curious: how do you name your member variables in VB.NET? And is there a "standard" way?

I'm not asking because I believe there's a "right" way or because I particularly want to change my style, and certainly not because I have any desire to tell others they're "wrong." Like I said, I'm just curious.

+3  A: 

I'm doing it like you.

 private _myVar as Object

 Public Property MyVar() As Object
          return me._myVar 
        End Get
        Set(ByVal value As Object)
          me._myVar = value
        End Set
    End Property

And in constructor

public sub new(myVar as object)
   me._myVar = myVar
end sub

But i think thats a matter of taste.

Tim Schmelter
After various attempts, I also decided to use the 'underscore' prefix for private members.
+2  A: 

The only time I use a prefix is with the private backing store for a public property. In these cases, the names are otherwise identical and most of the time the only place I'll ever reference the prefixed name is inside it's associated property. When I can finally use auto-implemented properties with VB.Net I won't even need to do that.

I do this in C# as well, on those instances when I can't just use an auto-implemented property. Better the _ prefix than varying the names only by case.

Joel Coehoorn
Justin Wignall
@Justin - I changed my answer a bit. I do have VS2010, but I'm not allowed to use the new feature yet because I'm also working on a bunch of code that still has to compile with vs2008. The result is that I keep forgetting it's there.
Joel Coehoorn
Sure, I know the 'pain'. Have taken the plunge though and must say it's a great time saving.
Justin Wignall
+2  A: 

I personally use m_ for member variables.

Although with automatic properties in VS 2010 I haven't needed to for any new code I've written recently.

Justin Wignall

Although a lot of the MS code seems to use m_* for private declarations, I save myself a character and just use _name for private members. My rules:

  • Private members are preceeded by an underscore
  • Public members (methods and properties) are PascalCase.
  • Parameters are camelCase.

Since I work in C#, having a parameter name with the same name as a property with different case is no problem. That won't work in VB, though.

David Lively
Parameters may of course have the same name as a property in VB. If you want to access the property instead of the parameter, just qualify the class: `Me.PropertyName`.
Konrad Rudolph
+3  A: 

I don’t like starting a line/name with an underscore since that always looks as if the line were indented by an additional space: it just makes the code unbalanced. Additionally, a lonely underscore is too inconspicuous for my taste: I prefer the identifiers to be clearly distinct.

Therefore, I periodically cycle between suffix underscore (e.g. example_) and prefix m_. I can’t decide which of those I prefer since I actually like neither. But the argument against prefix underscores partially also applies to suffix underscores.

But as you’ve remarked, some kind of distinction is necessary.

And as I’ve remarked elsewhere, I’ve had very bad experiences with case-only distinction in C# as well – it’s just too easy to confuse the names, and hence write into a private variable instead of the property. This matters if the property either checks or transforms the set value.

For that reason, I prefer to use some kind of prefix in C# as well.

Konrad Rudolph

We use _ (underscore) to prefix our variables names. It's short and to the point...

Private _ID as integer
Public Property ID() As Integer
        Return _ID
    End Get
    Set(ByVal value As Integer)
        _ID = value
    End Set
End Property
+2  A: 

It's personal preference, although there's widespread support for having some distinction. Even in C# I don't think there's one widely used convention.

Jeff Prosise says

As a matter of personal preference I typically prefix private fields with an underscore [in C#] ... This convention is used quite a lot in the .NET framework but it is not used throughout.

From the .NET Framework Design Guidelines 2nd Edition page 73.

Jeffrey Richter says

I make all my fields private and I prefix my instance fields with "m_" and my static fields with "s_" [in C#]

From the .NET Framework Design Guidelines 2nd Edition page 47. Anthony Moore (BCL team) also thinks using "m_" and "s_" is worth consideration, page 48.

I'm accepting this answer (just to accept one) because I greatly appreciate the references. If it's good enough for these guys, it's good enough for me (or to put it another way, if *these* guys are willing to ignore the whole "don't prefix member variables" suggestion, so am I).
Dan Tao