He visto demasiados códigos C# y C++ donde la convención de nomenclatura variable parece pedirles a los programadores que escriban nombres de variables usando guiones bajos antes del texto de la variable. p. ej.¿por qué C# y C++ usan la convención de codificación _ <nombreVariable>?
int? _countMoney;
¿Cuál es la razón de ser de esa convención?
En C# prefijo generalmente con _ campos privados, pero nunca variables locales. La razón detrás de esto es que cuando necesito una variable privada escribo _ y el Intellisense filtra la lista y es más fácil de encontrar. De esta forma, también puedo distinguir entre variables privadas y locales y ya no necesito escribir this.variablename para los campos de clase, sino simplemente _variablename.
Es solo una manera fácil de identificar las variables de miembros privados.
Como todas las demás convenciones, se trata de hacer que el código sea más fácil de entender.
Lo he visto como una convención para campos privados; en ese caso, es muy fácil ver que se usa un campo privado.
Puede formular la misma pregunta con respecto a hungarian notation.
Joel escribió una defensa interesante de la notación húngara: http://www.joelonsoftware.com/articles/Wrong.html –
¡La clave está usando la notación ** Aplicaciones húngara **, no ** Sistemas húngaros **! – CaffGeek
Si bien no soy un entusiasta de la notación húngara, si se usa para describir el valor de una variable, creo que es mucho más aceptable.Es cuando las personas lo usan para denotar algo así como el tipo de una variable que creo que se usa mal. En el artículo de Joel, él habla acerca de usar el prefijo "nosotros" para denotar "cuerdas inseguras". Yo diría que en un lenguaje moderno, como C#, si desea usar un prefijo como ese, el código sería más claro si ampliara el prefijo "nosotros" a "inseguro". –
A veces las personas hacen eso en las variables miembro para ayudar a distinguirlas de las variables locales. Si está accediendo directamente a una variable de subrayado, tal vez debería usar un getter/setter para acceder en su lugar.
¿Qué pasa con esta respuesta? Encuentro el punto perfectamente válido. – Lazer
Como otros han dicho, la convención de nomenclatura ayuda a distinguir las variables de los miembros de los locales. Esto da dos ventajas principales:
Previene de nomenclatura choques. Puedo escribir un constructor como:
SomeObject(int foo, int bar)
{
_foo = foo;
_bar = bar;
}
De esa manera, yo no tengo que nombrar los argumentos new_foo o algo por el estilo.
En C++ al menos, puede escribir un constructor como este: 'SomeObject (int foo, int bar): foo (foo), bar (bar) {}' y ocurre lo "correcto". –
@Oli: Lo que no necesariamente significa que realmente deberías estar haciendo esto ... – sbi
Es cierto. Esto es algo que aprendí en mis días C# (donde las listas de inicializadores de miembros no están permitidas, IIRC). –
No debe usar _ como prefijo en C++. Los nombres que comienzan con _ están reservados para el compilador.
El prefijo más común es C++ es m_ (como en 'miembro)
Para C# su muy común utilizar _.
En mi sitio donde hacemos la misma cantidad de C++ y C# siempre usamos m_ ser consistente
No, en C++ los nombres que comienzan con _Uppercase están reservados. _lowercase están bien. – Detmar
@Detmar: en realidad [es más complicado que eso] (http://stackoverflow.com/questions/3650623/trailing-underscores-for-member-variables-in-c/3651336#3651336), pero ambos todavía tienen un punto. – sbi
del estándar "Cada nombre que comienza con un guión bajo está reservado a la implementación para su uso como nombre en el espacio de nombre global". En teoría, puedes salirte con la tuya, pero ¿por qué esquivar el borde? – pm100
Las directrices de Microsoft para nombrar miembro especifica que usted no usa prefijos para los campos.
No use un prefijo para los nombres de los campos. Por ejemplo, no use g_ o s_ para distinguir campos estáticos versus campos no estáticos.
Puede leer las directrices de Microsoft para los nombres here. Esto solo se aplica a C#, por supuesto.
sigue siendo una práctica muy común que tiene mucho sentido ... –
Personalmente no me gusta la práctica de usar un prefijo. Su IDE debe aclararle qué es un local y qué es un miembro. Esto es, por supuesto, a gusto personal (o los estándares de codificación de su proyecto), pero esta respuesta obtiene mi +1. – rmeador
Esta es una de las pocas pautas con las que estoy en desacuerdo. Yo uso 'm_' y' s_' para distinguir entre instancia y campos estáticos. Esto es importante para mí, ya que debe suponer que se pueden acceder a los campos estáticos mediante varios subprocesos y, como tal, debe tener cuidado para evitar el problema del subprocesamiento. Usar los prefijos de esta manera hace que sea fácil ver de un vistazo si hay puntos problemáticos. Esta convención fue propuesta por Jeffery Richter, quien por casualidad tuvo voz en el desarrollo de esta guía. Debe haber perdido en este punto en particular :) –
Algo que noté por los desarrolladores de Java en Eclipse cuando tuve que hacer un trabajo en Java, no destacaron allí los vars. ¿Razón de ser? Los miembros vars tenían códigos de colores en el IDE ... no sentían la necesidad de hacerlo por así decirlo. Por costumbre, surgió de forma natural, ya que me resultaba fácil localizar un miembro var en el VS IDE por medio de una señal visual ... y un guión bajo, ya que era bastante popular. En el raro caso de que tenga que mirar el código en su forma más pura ... texto ... ese tipo de cosas ayuda enormemente.
No estoy seguro de cuál es la razón detrás de esta convención. Personalmente, no me importa el uso de ningún tipo de prefijo de nombre de variable para denotar el alcance de una variable, ni me preocupa particularmente el uso de guiones bajos al nombrar algo. ¿Qué tiene de malo el uso de la palabra clave "this" y la adopción de una convención de nombres inferiores con camel para variables de miembros/instancias privadas?
public void IncrementFoo()
{
this.foo += 1;
}
Solo quedan 5 caracteres adicionales para escribir, pero es muy explícito. Si ha adoptado la convención de mayúsculas y minúsculas para sus variables de instancia privadas, esto le indica de inmediato que está accediendo a una variable de miembro/instancia privada, y no necesita usar ningún tipo de prefijo para denotarlo .
El prefijo _ es bastante esencial en VB.NET porque no distingue entre mayúsculas y minúsculas. Codificamos tanto en C# como en VB.NET, y por el bien de todos, es importante tener las mismas convenciones de nomenclatura en ambos idiomas.
+1 para mí también, la idea principal es el filtrado de variables. – Lazer
Estaba haciendo esto mucho antes de intellisense para poder distinguir las variables de los miembros. Fue un seguimiento de los días C++ y MS utilizando m_ para las variables miembro –
Si no puede determinar si una variable es local o no dentro de unos pocos segundos de mirar un método, ¿no podría argumentarse que su método podría ser demasiado complejo? En cuanto al filtrado Intellisense, ¿es realmente una buena idea escribir código adaptado a una característica específica de un IDE? –