5

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.

Glorfindel
  • 21,988
  • 13
  • 81
  • 109
Dan Tao
  • 125,917
  • 54
  • 300
  • 447
  • possible duplicate of [Microsoft VB.NET naming convention](http://stackoverflow.com/questions/668157/microsoft-vb-net-naming-convention) – Hans Olsson Jun 09 '10 at 13:49
  • @ho1: Every time I come across somebody talking about naming conventions, they discuss basically every possible thing you could name except for private members. I'm just curious how people name specifically their private member variables. – Dan Tao Jun 09 '10 at 13:51
  • 2
    Is it just me that reads "I'm just curious how people name specifically their private member variables." as a little bit rude? ;) – Justin Wignall Jun 09 '10 at 13:59
  • I disagree with the quoted statement. this is overly verbose and just clutters up the code with a lot of noise. But, many, many people disagree with me on this. – 3Dave Jun 09 '10 at 14:02
  • @David: it’s only used to *distinguish* between the two usages, if necessary. Usually, you don’t need that so you don’t need the added `Me.`. – Konrad Rudolph Jun 09 '10 at 14:08
  • @Dan Tao: Well, in that case it's a duplicate of http://stackoverflow.com/questions/7642/naming-convention-for-vb-net-private-fields :) – Hans Olsson Jun 09 '10 at 14:12
  • @ho1: Fair enough! I'm fine with closing this question, then. I've already got some good answers anyway ;) – Dan Tao Jun 09 '10 at 14:59

7 Answers7

4

I'm doing it like you.

Private _myVar as Object

Public Property MyVar() As Object
    Get
        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 that's a matter of taste.

Dan Atkinson
  • 11,391
  • 14
  • 81
  • 114
Tim Schmelter
  • 450,073
  • 74
  • 686
  • 939
  • After various attempts, I also decided to use the 'underscore' prefix for private members. – Drake Jun 09 '10 at 13:54
  • Sorry to ask a question on an old post, but is having both me and _ *me._* not overkill? I'm sure it's my understanding (or lack of) but I assume this is just preference and having both me and _ doesn't offer any programming advantages/disadvantages? – Dave Feb 21 '13 at 10:16
  • @DaveRook: If you mean the `Me`, imho it cannot be clear enough and two letters doesn't cost that much. You could also use the property: `Me.MyVar = myVar`. The `Me` also prevents from accidential infinite loops. – Tim Schmelter Feb 21 '13 at 10:22
  • @TimSchmelter , once again, thank you. I always use Me or This (but not the underscore). Nice clear answer and I leave with a better understanding. Beers on me again! – Dave Feb 21 '13 at 11:05
4

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.

Glorfindel
  • 21,988
  • 13
  • 81
  • 109
MarkJ
  • 30,070
  • 5
  • 68
  • 111
  • 1
    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 Jun 09 '10 at 17:23
3

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
  • 3,490
  • 20
  • 23
3

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
  • 530,221
  • 131
  • 937
  • 1,214
2

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
  • 399,467
  • 113
  • 570
  • 794
  • http://weblogs.asp.net/scottgu/archive/2010/04/05/automatic-properties-collection-initializers-and-implicit-line-continuation-support-with-vb-2010.aspx – Justin Wignall Jun 09 '10 at 13:57
  • @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 Jun 09 '10 at 14:00
  • Sure, I know the 'pain'. Have taken the plunge though and must say it's a great time saving. – Justin Wignall Jun 10 '10 at 09:49
  • It's not uncommon for a class which hosts a property to have a few methods which may need to write to backing variables directly. For example, if a class has `X` and `Y` properties and a `LocationChanged` event, setting `X` and then `Y` should fire two events, but it may be helpful to have a method which sets `_x` and then `Y`, or else sets `_x` and `_y` and then fires the event manually. Using a prefix makes it clear that the use of the internal variable was deliberate. – supercat Jan 19 '14 at 18:07
2

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

Private _ID as integer
Public Property ID() As Integer
    Get
        Return _ID
    End Get
    Set(ByVal value As Integer)
        _ID = value
    End Set
End Property
Walter
  • 2,540
  • 2
  • 30
  • 38
1

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.

3Dave
  • 28,657
  • 18
  • 88
  • 151
  • 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 Jun 09 '10 at 14:04