Naming convention for VB.NET private fields

问题

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?

回答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.

回答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.

回答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# :)

回答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.

回答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.

回答6:

I don't think there is an official naming convention, but i've seen that Microsoft use m_ in the Microsoft.VisualBasic dll (via reflector).

回答7:

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.

I haven't found anything better than the "_" for clarify and consistency. Cons include:

Not CLS compliant
Tends to get lost when VB draws horizontal lines across my IDE

I get around the lines by turning those off in the editor, and try not to think too much about the CLS compliance.

回答8:

I agree with @lomaxx, it's more important to be consistent throughout the team than to have the right convention.

Still, here are several good places to get ideas and guidance for coding conventions:

Practical Guidelines and Best Practices for Microsoft Visual Basic and Visual C# Developers by Francesco Balena is a great book that addresses many of these issues.
IDesign Coding Standards (for C# and for WCF)
The .NET Framework Source Code (in VS2008)

回答9:

I prefer to use the underscore prefix for private fields. I use lowercase first letter for the method parameters. I follow the guideline of having lowercase camelcase parameters for methods, which I regard as more important than the naming of private fields since it is part of the API for the class. . e.g.

Public Class Class1

    Private _foo As String
    Public Property Foo() As String
        Get
            Return _foo
        End Get
        Set(ByVal value As String)
            _foo = value
        End Set
    End Property

    Public Sub New(ByVal foo As String)
        _foo = foo
    End Sub

End Class

Using this pattern, you won't have any naming conflicts with the private field and your constructor parameter in C# or VB.NET.

回答10:

I agree most important is not what style one uses but it being consistent.

With that said, the new MS/.NET styling for private fields tends to be _fooVar (underscore followed by a camelCased name)

来源：https://stackoverflow.com/questions/7642/naming-convention-for-vb-net-private-fields

标签

vb.net

convention