Convención de nomenclatura para campos privados de VB.NET

Question

¿Existe una convención oficial para nombrar campos privados en VB.NET?Por ejemplo, si tengo una propiedad llamada 'Foo', normalmente llamo al campo privado '_Foo'.Esto parece estar mal visto en el Directrices oficiales:

"No utilice un prefijo para los nombres de los campos.Por ejemplo, no utilice g_ o s_ para distinguir campos estáticos de no estáticos".

En C#, puede llamar al campo privado 'foo', la propiedad 'Foo' y hacer referencia al campo privado como 'this.foo' en el constructor.Como VB.NET no distingue entre mayúsculas y minúsculas, no puede hacer esto. ¿Alguna sugerencia?

Answer 1

Todavía uso el prefijo _ en VB para campos privados, así que tendré _foo como campo privado y Foo como propiedad.También hago esto para C# y para prácticamente cualquier código que escribo.En general, no me dejaría atrapar demasiado por "cuál es la manera correcta de hacerlo" porque en realidad no existe una manera "correcta" (aunque hay algunas muy malas), sino que me preocuparía por hacerlo de manera consistente.

Al final del día, ser coherente hará que su código sea mucho más legible y fácil de mantener que utilizar cualquier conjunto de convenciones "correctas".

Answer 2

Es una preferencia personal, aunque existe un amplio apoyo a tener alguno distinción.Incluso en C# no creo que exista una convención ampliamente utilizada.

Jeff Prosise dice

Como cuestión de preferencia personal, normalmente prefiero los campos privados con un guión bajo [en C#]...Esta convención se usa bastante en el marco .NET pero no se usa en todas partes.

Desde el .NET Framework Directrices de diseño 2ª Edición página 73.

Jeffrey Richter dice

Hago que todos mis campos sean privados y antepongo a mis campos de instancia "m_" y a mis campos estáticos "s_" [en C#]

Desde el .NET Framework Directrices de diseño 2ª Edición página 47.Antonio Moore (equipo bcl) también cree que vale la pena considerar el uso de "m_" y "s_", página 48.

Answer 3

Las pautas oficiales son sólo eso: pautas.Siempre puedes rodearlos.Dicho esto, normalmente ponemos como prefijo los campos con un guión bajo en ambos C# y VB.NET.Esta convención es bastante común (y obviamente, las Directrices Oficiales la ignoran).

Luego se puede hacer referencia a campos privados sin la palabra clave "yo" (la palabra clave "esta" es para C# :)

Answer 4

Las pautas de diseño que vinculó establecen específicamente que solo se aplican a campos públicos y protegidos estáticos.Las pautas de diseño se centran principalmente en el diseño de API públicas;Lo que hagas con tus miembros privados depende de ti.No estoy seguro, pero estoy relativamente seguro de que los miembros privados no se consideran cuando el compilador verifica el cumplimiento de CLS, porque solo los miembros públicos/protegidos entran en juego allí (la idea es: "¿Qué pasa si alguien que usa un lenguaje que ¿No permite que el personaje _ intente usar tu biblioteca?" Si los miembros son privados, la respuesta es "Nada, el usuario no tiene que usar estos miembros". pero si los miembros son públicos, estás en problemas. )

Dicho esto, voy a añadir algo más a la cámara de eco y señalar que hagas lo que hagas, es importante ser coherente.Mi empleador exige que los campos privados tanto en C# como en VB tengan el prefijo _, y como todos seguimos esta convención, es fácil usar código escrito por otra persona.

Answer 5

En VB.NET 4.0, la mayoría de ustedes probablemente saben que no necesitan escribir captadores y definidores explícitamente para sus declaraciones de propiedad de la siguiente manera:

Public Property Foo As String
Public Property Foo2 As String

VB crea automáticamente variables miembro privadas llamadas _Foo y _Foo2.Parece que Microsoft y el equipo de VS han adoptado la convención _, por lo que no veo ningún problema en ella.

Answer 6

No creo que exista una convención de nomenclatura oficial, pero he visto que Microsoft usa m_ en la dll Microsoft.VisualBasic (a través del reflector).

Answer 7

Todavía uso el prefijo _ en VB para campos privados, por lo que tendré _foo como campo privado y foo como propiedad.También hago esto para C# y prácticamente cualquier código que escriba.En general, no me quedaría demasiado atrapado en "cuál es la forma correcta de hacerlo" porque realmente no hay una forma "correcta" (aunque hay algunas maneras muy malas), sino que me preocupa hacerlo de manera consistente.

No he encontrado nada mejor que el "_" para mayor claridad y coherencia.Las desventajas incluyen:

• No compatible con CLS
• Tiende a perderse cuando VB dibuja líneas horizontales en mi IDE

Salto de las líneas desactivándolas en el editor y trato de no pensar demasiado en el cumplimiento de CLS.

Answer 8

Estoy de acuerdo con @lomaxx, es más importante ser consistente en todo el equipo que tener la bien convención.

Aún así, aquí hay varios buenos lugares para obtener ideas y orientación para las convenciones de codificación:

1. Directrices prácticas y mejores prácticas para Microsoft Visual Basic y Visual C# Desarrolladores de Francesco Balena es un gran libro que aborda muchas de estas cuestiones.
2. Estándares de codificación IDesign (para C# y para WCF)
3. El marco .NET Código fuente (en VS2008)

Answer 9

Prefiero utilizar el prefijo de guión bajo para campos privados.Utilizo la primera letra minúscula para los parámetros del método.Sigo la pauta de tener parámetros en minúsculas en camello para los métodos, lo cual considero más importante que el nombre de los campos privados, ya que es parte de la API de la clase..p.ej.

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

Al utilizar este patrón, no tendrá ningún conflicto de nombres con el campo privado y su parámetro de constructor en C# o VB.NET.

Answer 10

Estoy de acuerdo en que lo más importante no es el estilo que uno usa, sino la coherencia.

Dicho esto, el nuevo estilo de MS/.NET para campos privados tiende a ser _fooVar (guión bajo seguido de un nombre camelCased)