En realidad, la _varconvención proviene de VB, no de C # o C ++ (m _, ... es otra cosa).
Esto llegó a superar la insensibilidad de VB al declarar Propiedades.
Por ejemplo, dicho código no es posible en VB porque lo considera usery Usercomo el mismo identificador
Private user As String
Public Property User As String
Get
Return user
End Get
Set(ByVal Value As String)
user = value
End Set
End Property
Entonces, para superar esto, algunos usaron una convención para agregar '_' al campo privado para venir así
Private _user As String
Public Property User As String
Get
Return _user
End Get
Set(ByVal Value As String)
_user = value
End Set
End Property
Dado que muchas convenciones son para .Net y para mantener cierta uniformidad entre las convenciones de C # y VB.NET, están utilizando la misma.
Encontré la referencia de lo que estaba diciendo:
http://10rem.net/articles/net-naming-conventions-and-programming-standards---best-practices
Estuche Camel con guión bajo destacado. En VB.NET, siempre indique "Protegido" o "Privado", no use "Dim". Se desaconseja el uso de "m_", al igual que el uso de un nombre de variable que difiere de la propiedad por un solo caso, especialmente con variables protegidas, ya que viola el cumplimiento y hará que su vida sea difícil si programa en VB.NET, ya que tendría que nombrar a sus miembros como algo diferente de las propiedades de acceso / mutador. De todos los elementos aquí, el guión bajo principal es realmente el único controvertido. Personalmente, prefiero el caso de camello directo sin guión bajo para mis variables privadas, de modo que no tenga que calificar los nombres de variables con "esto". para distinguir de los parámetros en los constructores o en otros lugares donde probablemente tenga una colisión de nombres. Con la insensibilidad a mayúsculas y minúsculas de VB.NET, esto es aún más importante ya que sus propiedades de acceso generalmente tendrán el mismo nombre que sus variables de miembro privadas, excepto el guión bajo. En lo que respecta a m_, en realidad se trata solo de estética. Yo (y muchos otros) encuentro m_ feo, ya que parece que hay un agujero en el nombre de la variable. Es casi ofensivo. Solía usarlo en VB6 todo el tiempo, pero eso fue solo porque las variables no podían tener un guión bajo destacado. No podría estar más feliz de verlo desaparecer. Microsoft recomienda contra m_ (y la recta _) a pesar de que hicieron ambas cosas en su código. Además, el prefijo con una "m" recta es correcto. Por supuesto, dado que codifican principalmente en C #, pueden tener miembros privados que difieren solo en el caso de las propiedades. La gente de VB tiene que hacer otra cosa. En lugar de tratar de encontrar casos especiales de idioma por idioma, recomiendo el subrayado líder para todos los idiomas que lo admitirán. Si quiero que mi clase sea totalmente compatible con CLS, podría dejar el prefijo en cualquier variable miembro protegida de C #. En la práctica, sin embargo, nunca me preocupo por esto, ya que mantengo privadas todas las variables miembro potencialmente protegidas y en su lugar proporciono accesores y mutadores protegidos. Por qué: en pocas palabras, esta convención es simple (un carácter), fácil de leer (su ojo no se distrae con otros personajes principales) y evita con éxito nombrar colisiones con variables de nivel de procedimiento y propiedades de nivel de clase. . Recomiendo el guión bajo principal para todos los idiomas que lo admitirán. Si quiero que mi clase sea totalmente compatible con CLS, podría dejar el prefijo en cualquier variable miembro protegida de C #. En la práctica, sin embargo, nunca me preocupo por esto, ya que mantengo privadas todas las variables miembro potencialmente protegidas y en su lugar proporciono accesores y mutadores protegidos. Por qué: en pocas palabras, esta convención es simple (un carácter), fácil de leer (su ojo no se distrae con otros personajes principales) y evita con éxito nombrar colisiones con variables de nivel de procedimiento y propiedades de nivel de clase. . Recomiendo el guión bajo principal para todos los idiomas que lo admitirán. Si quiero que mi clase sea totalmente compatible con CLS, podría dejar el prefijo en cualquier variable miembro protegida de C #. En la práctica, sin embargo, nunca me preocupo por esto, ya que mantengo privadas todas las variables miembro potencialmente protegidas y en su lugar proporciono accesores y mutadores protegidos. Por qué: en pocas palabras, esta convención es simple (un carácter), fácil de leer (su ojo no se distrae con otros personajes principales) y evita con éxito nombrar colisiones con variables de nivel de procedimiento y propiedades de nivel de clase. . Nunca me preocupo por esto, ya que mantengo privadas todas las variables miembro potencialmente protegidas y, en su lugar, proporciono accesores y mutadores protegidos. Por qué: en pocas palabras, esta convención es simple (un carácter), fácil de leer (su ojo no se distrae con otros personajes principales) y evita con éxito nombrar colisiones con variables de nivel de procedimiento y propiedades de nivel de clase. . Nunca me preocupo por esto, ya que mantengo privadas todas las variables miembro potencialmente protegidas y, en su lugar, proporciono accesores y mutadores protegidos. Por qué: en pocas palabras, esta convención es simple (un carácter), fácil de leer (su ojo no se distrae con otros personajes principales) y evita con éxito nombrar colisiones con variables de nivel de procedimiento y propiedades de nivel de clase. .