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 Offical Guidelines:

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

En C#, puede llamar al campo privado 'foo', la propiedad 'Foo', y referirse 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, por lo que tendré _foo como campo privado y Foo como propiedad. Hago esto también para C# y casi cualquier código que escribo. En general, no me quedaría demasiado atrapado en "cuál es la forma correcta de hacerlo" porque no hay realmente una manera "correcta" (aunque hay algunas maneras muy malas) sino más bien estar preocupado por hacerlo de manera consistente.

Al final del día, ser consistente hará que su código sea mucho más legible y mantenible que usar cualquier conjunto de convenciones "correctas".

Answer 2

Las pautas oficiales son solo eso: directrices. Siempre puedes rodearlos. Dicho esto, usualmente prefijamos los campos con un guión bajo en ambos C# y VB.NET. Esta convención es bastante común (y obviamente, las Pautas oficiales ignoradas).

campos privados continuación, se puede hacer referencia sin la palabra clave "yo" (la palabra "this" es para C# :)

Answer 3

No creo que hay una convención de nomenclatura oficial, pero he visto que Microsoft use m_ en Microsoft.VisualBasic dll (vía reflector).

Answer 4

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

Sin embargo, aquí hay varios buenos lugares para obtener ideas y orientación para las convenciones de codificación:

1. Practical Guidelines and Best Practices for Microsoft Visual Basic and Visual C# Desarrolladores de Francesco Balena es un gran libro que aborda muchos de estos problemas.
2. IDesign Coding Standards (para C# y para WCF)
3. .NET Framework Source Code (en VS2008)

Answer 5

yo prefiero usar el prefijo de subrayado para campos privados. Uso la primera letra minúscula para los parámetros del método. Sigo la pauta de tener parámetros de minúsculas camelcase para los métodos, que considero más importante que el nombre de 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 

El uso de este patrón, que no tendrán los conflictos de nombre con el ámbito privado y el parámetro de constructor en C# o VB.NET.

Answer 6

todavía puedo usar el prefijo _ en VB para campos privados, así que tendré _foo como el campo privado y Foo como la propiedad . Hago esto también para C# y casi cualquier código que escribo. En general, no me quedaría demasiado atrapado en "¿cuál es la manera correcta de hacerlo?" porque no existe realmente una forma "correcta" (aunque hay algunas formas muy malas ), sino más bien estar preocupado con haciéndolo consistentemente.

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

• Not CLS compliant
• tiende a perderse cuando VB dibuja líneas horizontales a través de mi IDE

llego alrededor de las líneas girando los apagado en el editor, y trato de no pensar demasiado mucho sobre el cumplimiento de CLS.

Answer 7

Las pautas de diseño que ha vinculado específicamente establecen que solo se aplican a campos estáticos públicos y protegidos. 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 son considerados cuando el compilador verifica el cumplimiento de CLS, porque solo los miembros públicos/protegidos entran para jugar allí (la idea es: "¿Qué pasa si alguien que usa un idioma 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 agregar 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 en C# y VB tengan el prefijo _, y como todos nosotros seguimos esta convención, es fácil usar código escrito por otra persona.

Answer 8

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

Con eso dicho, el nuevo estilo/.NET MS para campos privados tiende a ser _fooVar (guión bajo seguido por un nombre CamelCased)

Answer 9

Es preferencia personal, aunque hay un amplio apoyo por tener algunos distinción. Incluso en C# no creo que haya una convención ampliamente utilizada.

Jeff Prosise dice

Como una cuestión de preferencia personal me campos privados normalmente prefijo con un guión bajo [en C#] ... Esta convención se utiliza mucho en el marco .NET, pero no se usa en todo.

Desde. NET Framework Design Guidelines segunda página de edición 73.

Jeffrey Richter dice

hago todos mis campos privados y prefijo de mis campos de instancia con "m_" y mis campos estáticos con "s_" [en C#]

Desde. NET Framework Design Guidelines 2nd Edition página 47. Anthony Moore (BCL team) también considera que vale la pena utilizar "m_" y "s_", página 48.

Answer 10

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

Public Property Foo As String 
Public Property Foo2 As String 

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