Naming convention for VB.NET private fields

Question

Is there an official convention for naming private fields in VB.NET? For example, if I have a property called 'Foo', I normally call the private field '_Foo'. This seems to be frowned upon in the Offical Guidelines:

"Do not use a prefix for field names. For example, do not use g_ or s_ to distinguish static versus non-static fields."

In C#, you could call the private field 'foo', the property 'Foo', and refer to the private field as 'this.foo' in the constructor. As VB.NET is case insensitive you can't do this - any suggestions?

Solution 1

I still use the _ prefix in VB for private fields, so I'll have _foo as the private field and Foo as the property. I do this for c# as well and pretty much any code I write. Generally I wouldn't get too caught up in "what is the right way to do it" because there isn't really a "right" way (altho there are some very bad ways) but rather be concerned with doing it consistently.

At the end of the day, being consistent will make your code much more readable and maintainable than using any set of "right" conventions.

Solution 2

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.

Solution 3

Official guidelines are just that -- guidelines. You can always go around them. That being said we usually prefix fields with an underscore in both C# and VB.NET. This convention is quite common (and obviously, the Official Guidelines ignored).

Private fields can then be referenced without the "me" keyword (the "this" keyword is for C# :)

Solution 4

The design guidelines that you linked specifically state that they only apply to static public and protected fields. The design guidelines mostly focus on designing public APIs; what you do with your private members is up to you. I'm not positive but I'm relatively confident that private members are not considered when the compiler checks for CLS compliance, because only public/protected members come in to play there (the idea is, "What if someone who uses a language that doesn't allow the _ character tries to use your library?" If the members are private, the answer is "Nothing, the user doesn't have to use these members." but if the members are public you're in trouble.)

That said, I'm going to add to the echo chamber and point out that whatever you do, it's important to be consistent. My employer mandates that private fields in both C# and VB are prefixed with _, and because all of us follow this convention it is easy to use code written by someone else.

Solution 5

In VB.NET 4.0, most of you probably know you don't need to explicitly write getters and setters for your Property declarations as follows:

Public Property Foo As String
Public Property Foo2 As String

VB automatically creates private member variables called _Foo and _Foo2. It seems as though Microsoft and the VS team have adopted the _ convention, so I don't see an issue with it.

View more solutions

Comments

[MarkJ]

Those official guidelines are for developing class libraries, and only apply to the public elements not the private ones.

[Jonathan Allen]

CLS compliance doesn't care about private field names.