Marcar el prefijo en las variables miembro. intellisense

Question

Todos dijeron que el debate "subrayar, no subrayar" es puramente filosófico y orientado a las preferencias del usuario, pero con intelli-sense tiene el subrayado que le permite diferenciar sus variables miembro de su variable local muy fácilmente y así darle un beneficio concreto

¿Existe algún argumento en contra de este beneficio de tener caracteres de subrayado para todas las variables miembro?

Answer 1

Sí, para algunas personas reduce la legibilidad. Creo que diferentes personas leen de diferentes maneras (algunos vocalizan internamente y otros no, por ejemplo). Para algunas personas (incluido yo mismo), los guiones bajos interrumpen el "flujo" de código cuando lo estoy leyendo.

Argumentaría que si tiene dificultades para distinguir las variables locales y de instancia, entonces posiblemente sus métodos sean demasiado grandes o su clase esté haciendo demasiado. Ese no siempre será el caso, por supuesto, pero no suelo encontrarlo en absoluto con clases/métodos cortos.

Answer 2

Usar subrayado es solo una forma de lograr ese efecto. Lo importante es ser consecuente al respecto.

Answer 3

Si es solo el intellisense que desea, siempre puede obtenerlo escribiendo "this.".

OK, son 4 caracteres más que "_", pero el intellisense mostrará sus miembros por usted.

Si usa guiones bajos y su equipo utiliza guiones bajos, continúe usándolos. Otros usarán "m _", otros pueden tener otras ideas. Uso StyleCop y en mi equipo el debate ha terminado, usamos "this". y el estilo húngaro o los prefijos de subrayado no se usan. Y ya no nos preocupamos más.

[Editar] Esto no es una crítica a su pregunta, es una pregunta válida y vale la pena preguntar, pero este debate desperdicia demasiado tiempo en proyectos de desarrollo. A pesar de que no me gusta todo sobre StyleCop, lo uso de buena gana ya que corta este tipo de debate. En serio, he estado en reuniones de una hora donde este tipo de debate ocupa todo un equipo de desarrollo. Loca. Como dije, su pregunta es válida, pero no pierda su propio tiempo agonizando por esto, no vale la pena :-)

Answer 4

Realmente no importa qué convención de nomenclatura elija siempre que la use en todo el proyecto.

Answer 5

El guión bajo se puede ver como una forma de notación húngara *, pero el prefijo es un "carácter mágico" en lugar de algo que tiene un significado.

Si quiere algo que diga más sobre para qué sirve el prefijo, debería usar un prefijo como member o mbr o m. A veces se usa el prefijo m_, pero luego el subrayado se usa como separador en lugar de una parte del prefijo, y las recomendaciones de nomenclatura para .NET indican que no se debe usar como separador.

Personalmente, me ha gustado el guión bajo para las variables miembro, aunque es un prefijo con un significado oculto. No satura los nombres tanto como lo haría cualquier otro prefijo.

Y, como siempre, es más importante elegir un estándar y atenerse a él, que el estándar que elija.

---

* notaition húngaro ha provenido principalmente para ser utilizado para especificar el tipo de datos en lenguajes de tipos débiles como VBScript, pero la intención original de especificar otras propiedades de las variables, por lo que usar para las variables miembro está más a lo largo del original intenciones

Answer 6

Usando esto. en todas partes reduce la legibilidad en mi opinión. Los prefijos de subrayado para campos de clase privados son perfectamente aceptables. Es apenas húngaro, que es una convención de nombres realmente horrible y en el tipo de letra frente a intellisense, más una letra es una forma extremadamente rápida de mostrar tu lista. Uso CSLA.NET y muchos de los ejemplos de BO usan la convención de subrayado y continúo utilizándola en todo mi trabajo. No permita que los desarrolladores de C++ y C de la vieja escuela lo asusten y lo lleven a pensar que no es una buena práctica: .NET no sufre los mismos problemas. Un buen ejemplo es el paso de argumentos en los constructores:

public MyObject(int field1, int field2, int field3) 
{ 
    _field1 = field1; 
    _field2 = field2; 
    _field3 = field3; 
} 

En mi opinión es mucho más legible que

public MyObject(int field1, int field2, int field3) 
{ 
    this.field1 = field1; 
    this.field2 = field2; 
    this.field3 = field3; 
} 

Pero es gusto personal y como se ha dicho en otra parte la consistencia es la cuestión más importante.