vb.net - c# coding conventions

Convenciones 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 las Pautas oficiales :

"No use un prefijo para nombres de campo. Por ejemplo, no use g_ o s_ para distinguir campos estáticos frente a campos 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

Estoy de acuerdo con @lomaxx, es más importante ser coherente 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. Pautas prácticas y mejores prácticas para desarrolladores de Microsoft Visual Basic y Visual C por Francesco Balena es un excelente libro que aborda muchos de estos problemas.
2. Estándares de codificación IDesign (para C # y para WCF)
3. El código fuente de .NET Framework (en VS2008)

Answer 2

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

Los campos privados pueden ser referenciados sin la palabra clave "yo" (la palabra clave "this" es para C # :)

Answer 3

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

Answer 4

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

Al usar este patrón, no tendrá conflictos de nomenclatura con el campo privado y su parámetro de constructor en C # o VB.NET.

Answer 5

Sigo usando el prefijo _ en VB para campos privados, así 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 consecuente hará que su código sea mucho más legible y mantenible que usar cualquier conjunto de convenciones "correctas".

Answer 6

Sigo usando el prefijo _ en VB para campos privados, así 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.

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

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

Salto las líneas apagándolos en el editor y trato de no pensar demasiado sobre el cumplimiento de CLS.

Answer 7

Las pautas de diseño que vinculó especifican 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 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 sea lo que sea que hagas, es importante ser consecuente. 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 qué estilo uno usa, sino que es consistente.

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

Answer 9

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

Jeff Prosise dice

Como una cuestión de preferencia personal prefijo campos privados con un guión bajo [en C #] ... Esta convención se usa bastante en .NET Framework pero no se usa en todas partes.

Desde el . NET Framework Design Guidelines 2nd Edition página 73.

Jeffrey Richter dice

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

Desde el . NET Framework Design Guidelines 2nd Edition página 47. Anthony Moore ( equipo de BCL ) también piensa que usar "m_" y "s_" merece consideración, página 48.

Answer 10

En VB.NET 4.0, la mayoría de ustedes probablemente saben que no es necesario escribir explícitamente getters y setters para sus declaraciones de propiedades 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 VS han adoptado la convención, por lo que no veo ningún problema.