Subrayar o no subrayar, esa es la pregunta

¿Hay algún problema al no anteponer campos privados con un guión bajo en C # si la versión binaria va a ser consumida por otros lenguajes de framework? Por ejemplo, dado que C # distingue entre mayúsculas y minúsculas, puede llamar a un campo "foo" y a la propiedad pública "Foo", y funciona bien.

¿Tendría algún efecto en un lenguaje que no distinga entre mayúsculas y minúsculas, como VB.NET, por algún problema de cumplimiento de CLS (u otros) si los nombres solo se distinguen por mayúsculas y minúsculas?

Se tendrá ningún efecto.

Parte de las recomendaciones para escribir bibliotecas compatibles con CLS es NO tener dos entidades públicas / protegidas que difieran solo por caso, por ejemplo, NO debería tener

public void foo() {...}

y

public void Foo() {...}

lo que está describiendo no es un problema porque el elemento privado no está disponible para el usuario de la biblioteca

ACTUALIZACIÓN IMPORTANTE (12 de abril de 2016):

Se nos señaló que el estándar interno del equipo .NET CoreFX insiste en usar la notación de subrayado sin dar ninguna idea de por qué. Sin embargo, si nos fijamos bien en la regla # 3 se hace evidente que existe un sistema de _, t_, s_prefijos que sugiere por qué _fue elegido en el primer lugar.

3. Usamos _camelCasepara campos internos y privados y utilizamos solo lectura cuando sea posible. Prefijar campos de instancia con _, campos estáticos con s_y campos estáticos de subprocesos con t_. Cuando se usa en campos estáticos, readonlydebe aparecer después static(es decir, static readonlyno readonly static).
4. Evitamos a this.menos que sea absolutamente necesario.

Entonces, si usted es como el equipo de .NET CoreFX que trabaja en un código de nivel de sistema crítico, multiproceso y de rendimiento crítico, le SUGERIMOS FUERTEMENTE:

• adherirse a sus estándares de codificación y
• use la notación de subrayado y
• no lea más esta respuesta

De lo contrario, sigue leyendo ...

LA RESPUESTA ORIGINAL:

Primero pongamos de acuerdo de lo que estamos hablando. La pregunta es cómo accedemos a los miembros de la instancia desde métodos y constructores no estáticos de una clase / subclase si los modificadores de visibilidad lo permiten.

Notación de subrayado

• sugiere que use el prefijo "_" en los nombres de los campos privados
• también dice que nunca debe usar "esto" a menos que sea absolutamente necesario

Esta notación

• sugiere que siempre uses "esto". para acceder a cualquier miembro de la instancia

¿Por qué existe esta notación?

Porque así es como tú

• distinguir un parámetro de un campo cuando comparten el mismo nombre
• asegúrese de estar trabajando en el contexto de la instancia actual

Ejemplo

public class Demo
{
   private String name;
   public Demo(String name) {
       this.name = name;
   }
}

¿Por qué existe la notación de subrayado?

A algunas personas no les gusta escribir "esto", pero aún necesitan una forma de distinguir un campo y un parámetro, por lo que acordaron usar "_" delante de un campo

Ejemplo

public class Demo
{
   private String _name;
   public Demo(String name) {
      _name = name;
   }
}

Uno puede pensar que es solo cuestión de gustos personales y que ambas formas son igualmente buenas / malas. Sin embargo, hay ciertos aspectos en los que esta notación supera a la notación de subrayado:

Claridad

• nombres de desorden de guiones bajos
• esta notación mantiene los nombres intactos

Carga cognitiva

• la notación de subrayado es inconsistente, te hace tratar los campos de una manera especial, pero no puedes usarlo con otros miembros, cada vez que necesites preguntarte si necesitas una propiedad o un campo

• esta notación es consistente, no tienes que pensar, siempre usas "this" para referirte a cualquier miembro

ACTUALIZACIÓN: como se señaló, lo siguiente no es un punto de ventaja

Mantenimiento

• la notación de subrayado requiere que _vigiles mientras refactorizas, por ejemplo, convertir un campo en propiedad (eliminar _) o lo contrario (agregar _)

• esta notación no tiene ese problema

Autocompletado

Cuando necesite ver la lista de miembros de la instancia:

• la notación de subrayado no le ayuda mucho, porque cuando escribe "_", la ventana emergente de autocompletar le muestra los campos privados y todos los tipos disponibles de los ensamblados vinculados mezclados con el resto de los miembros de la instancia
• esta notación le da una respuesta clara, escribiendo "esto" todo lo que ve es la lista de miembros y nada más

Ambigüedad

A veces tienes que lidiar con el código sin la ayuda de Intellisense. Por ejemplo, cuando realiza revisiones de código o explora el código fuente en línea.

• la notación de subrayado es ambigua: cuando ve Something.SomethingElse no puede decir si Something es una clase y SomethingElse es su propiedad estática ... o tal vez Something es una propiedad de instancia actual que tiene su propia propiedad de SomethingElse

• esta notación es clara: cuando ves Something.SomethingElse solo puede significar una clase con una propiedad estática y cuando ves this.Something.SomethingElse sabes que Something es miembro y SomethingElse es su propiedad

Métodos de extensión

No puede usar métodos de extensiones en la instancia misma sin usar "this".

• la notación de subrayado requiere que no use "esto", sin embargo, con los métodos de extensión debe
• esta notación lo salva de dudas, siempre usa "esto", punto.

Soporte de Visual Studio

• la notación de subrayado no tiene soporte incorporado en Visual Studio

• Visual Studio admite esta notación de forma natural:

  1. "Esta." Calificación : Prefiera que todos los campos no estáticos utilizados en métodos no estáticos sean precedidos this.en C #

Recomendaciones oficiales

Hay muchas pautas oficiales que dicen claramente "no use guiones bajos", especialmente en C #

• la notación de subrayado proviene de C ++, donde es una práctica general que ayuda a evitar conflictos de nombres, también se recomienda para VisualBasic.Net para superar un problema en el que un campo "valor" y una propiedad "Valor" realmente tienen el mismo nombre, porque VisualBasic no distingue entre mayúsculas y minúsculas

  1. Nombres de elementos declarados en Visual Basic
  2. Copia de seguridad de campos en VisualBasic.NET

• Se recomienda esta notación para C # mientras que "_" está explícitamente prohibido:

  1. esta palabra clave en C #
  2. Pautas de uso de campo : no aplique un prefijo a los nombres de campo o nombres de campo estático.
  3. Pautas para los nombres: nombres de miembros de tipo : no utilice un prefijo para los nombres de campo.
  4. Convención de nomenclatura general : X NO use guiones bajos, guiones ni ningún otro carácter no alfanumérico
  5. Regla de afirmación de calidad CA1707 : los identificadores no deben contener guiones bajos
  6. El uso de guiones bajos no es compatible con CLS (para identificadores públicos y protegidos)
  7. Convención de nomenclatura interna de los desarrolladores de .NET Framework : no utilice un prefijo para las variables miembro. Si desea distinguir entre variables locales y miembros, debe usar "esto". en C # y "Yo". en VB.NET.

Tomado del archivo de ayuda de Microsoft StyleCop:

TypeName: FieldNamesMustNotBeginWithUnderscore

CheckId: SA1309

Causa: un nombre de campo en C # comienza con un guión bajo.

Descripción de la regla:

Se produce una violación de esta regla cuando un nombre de campo comienza con un guión bajo.

De forma predeterminada, StyleCop no permite el uso de guiones bajos, m_, etc., para marcar los campos de clase locales, a favor de 'this'. prefijo. La ventaja de usar 'esto'. es que se aplica por igual a todos los tipos de elementos, incluidos los métodos, propiedades, etc., y no solo a los campos, lo que hace que todas las llamadas a los miembros de la clase sean reconocibles al instante, independientemente del editor que se esté utilizando para ver el código. Otra ventaja es que crea una diferenciación rápida y reconocible entre los miembros de la instancia y los miembros estáticos, que no tendrán prefijo.

Si el nombre del campo o la variable está destinado a coincidir con el nombre de un elemento asociado con Win32 o COM, y por lo tanto necesita comenzar con un guión bajo, coloque el campo o la variable dentro de una clase especial de NativeMethods. Una clase NativeMethods es cualquier clase que contiene un nombre que termina en NativeMethods, y está destinada como un marcador de posición para los contenedores Win32 o COM. StyleCop ignorará esta violación si el elemento se coloca dentro de una clase NativeMethods.

Una descripción de regla diferente indica que la práctica preferida además de la anterior es comenzar campos privados con letras minúsculas y públicos con letras mayúsculas.

Editar: Como seguimiento, la página del proyecto StyleCop se encuentra aquí: https://github.com/DotNetAnalyzers/StyleCopAnalyzers . Leer el archivo de ayuda ofrece una gran comprensión de por qué sugieren varias reglas estilísticas.

Como estamos hablando de un campo privado, no afecta a un usuario de su clase.

Pero recomiendo usar un guión bajo para el campo privado, porque puede hacer que el código sea más fácil de entender, por ejemplo:

private int foo;
public void SetFoo(int foo)
{
  // you have to prefix the private field with "this."
  this.foo = foo;

  // imagine there's lots of code here,
  // so you can't see the method signature



  // when reading the following code, you can't be sure what foo is
  // is it a private field, or a method-argument (or a local variable)??
  if (foo == x)
  {
    ..
  }
}

En nuestro equipo, siempre usamos un prefijo de subrayado para campos privados. Por lo tanto, al leer algún código, puedo identificar fácilmente los campos privados y distinguirlos de los locales y los argumentos. En cierto modo, el guión bajo puede verse como una versión abreviada de "esto".

Después de trabajar en un entorno que tenía reglas de estilo muy específicas e inútiles desde entonces, creé mi propio estilo. Este es un tipo que he cambiado mucho de un lado a otro. Finalmente he decidido que los campos privados siempre serán _field, las variables locales nunca tendrán _ y serán minúsculas, los nombres de las variables para los controles seguirán libremente la notación húngara, y los parámetros generalmente serán camelCase.

Odio el this. palabra clave, en mi opinión, simplemente agrega demasiado ruido de código. Me encanta Resharper's eliminar esto redundante. palabra clave.

Actualización de 6 años: estaba analizando los aspectos internos de Dictionary<TKey,T>un uso específico de acceso concurrente y leí mal un campo privado como una variable local. Los campos privados definitivamente no deberían ser la misma convención de nomenclatura que las variables locales. Si hubiera habido un guión bajo, habría sido increíblemente obvio.

Me gusta el guión bajo, porque entonces puedo usar el nombre en minúscula como parámetros de método como este:

public class Person
{
    string _firstName;

    public MyClass(string firstName)
    {
        _firstName = firstName;
    }

    public string FirstName
    {
        get { return _firstName; }
    }
}

Todavía me gusta mucho usar guiones bajos delante de los campos privados por la razón que Martin mencionó, y también porque los campos privados se ordenarán en IntelliSense. Esto a pesar de la maldad de las anotaciones de prefijos húngaros en general.

Sin embargo, en los últimos tiempos encuentro que usar el prefijo de subrayado para miembros privados está mal visto, aunque no estoy muy seguro de por qué. Quizás alguien más lo sabe? ¿Es solo el principio del prefijo? ¿O hubo algo relacionado con el cambio de nombre de los tipos genéricos que reciben guiones bajos en ensamblajes compilados o algo así?

Recomendación de Style Cop o no, profundizar en .NET Framework muestra mucho uso "_" para las variables miembro. Lo que recomiendan los creadores de Style Cop, no es lo que la mayoría de los empleados de MS están usando. :) Así que me quedaré con el guión bajo. Debido a que personalmente cometo muchos menos errores usando el guión bajo y luego el this (ejemplo: usando varName = varName en lugar de this.varName = varName, realmente está atrapado en mí)

Creo que, en general, los campos de nivel de clase son un error en el diseño del lenguaje. Hubiera preferido que las propiedades de C # tuvieran su propio ámbito local:

public int Foo
{
   private int foo;
   get
   {
      return foo;
   }
   set
   {
      foo = value;
   }
}

Eso permitiría dejar de usar campos por completo.

La única vez que prefijo un campo privado con un guión bajo es cuando una propiedad requiere un campo de respaldo separado. Esa es también la única vez que uso campos privados. (Y como nunca uso campos protegidos, internos o públicos, esa es la única vez que uso el período de campos). En lo que a mí respecta, si una variable necesita tener alcance de clase, es una propiedad de la clase.

La notación _fieldName para campos privados es muy fácil de romper . Usando esto." La notación es imposible de romper. ¿Cómo romperías la notación _? Observar:

private void MyMethod()
{
  int _myInt = 1; 
  return; 
}

Ahí tienes, violé tu convención de nomenclatura pero se compila. Prefiero tener una convención de nomenclatura que sea a) no húngara yb) explícita. Estoy a favor de eliminar los nombres húngaros y esto califica de alguna manera. En lugar del tipo de un objeto delante del nombre de la variable, tiene su nivel de acceso.

Contraste esto con Ruby, donde el nombre de la variable @my_numbervincula el nombre al ámbito y es irrompible.

editar: esta respuesta se ha vuelto negativa. No me importa, se queda.

Cuando desee que su ensamblado cumpla con CLS, puede usar el atributo CLSCompliant en su archivo de información de ensamblaje. El compilador se quejará cuando su código contenga cosas que no son compatibles con cls.

Luego, cuando tiene 2 propiedades que solo difieren en el caso, el compilador emitirá un error. Por otro lado, cuando tenga un campo privado y una propiedad pública en la misma clase, no habrá problemas.

(Pero, siempre prefijo a mis miembros privados con un guión bajo. También me ayuda a dejar en claro cuando leo mi código que cierta variable es un campo de miembro).

Me gusta usar guiones bajos delante de mis campos privados por dos razones. Ya se ha mencionado uno, los campos se destacan de sus propiedades asociadas en código y en Intellisense. La segunda razón es que puedo usar las mismas convenciones de nomenclatura si estoy codificando en VB o C #.

No hay implicaciones de ningún tipo. Cuando se compila su código, todo lo que es importante para el compilador es el espacio de nombres y la visibilidad del campo / propiedad. Un guión bajo es tan significativo como cualquier otro carácter al nombrar un identificador. El verdadero truco es utilizar una convención que usted y las personas que lo rodean entenderán.