¿Cómo nombras tus variables privadas en C #? [cerrado]

¿Cuál es la mejor práctica, las convenciones de nomenclatura más comúnmente aceptadas para variables privadas en C #?

1. private int myInteger;
2. private int MyInteger;
3. private int mMyInteger;
4. private int _myInteger;
5. private int _MyInteger;
6. Otra opción misteriosa

¿Cuál usas y por qué? (Mi empresa es bastante nueva en C # y me gustaría elegir el método más "aceptado por la industria" para intentar entrar en nuestro estándar de codificación).

Las pautas de diseño de la clase MSDN http://msdn.microsoft.com/en-us/library/ta31s3bc.aspx recomiendan la opción 1: myInteger.

Siempre he usado este estilo. Tengo una aversión personal por el personaje _.

Yo uso la opción # 4 arriba:

private int _myInteger;

Me gusta tener alguna indicación de alcance en mis nombres de variables, y el guión bajo es suficiente para ese propósito. También es bastante fácil de leer.

Yo uso el siguiente esquema de nombres:

• 1er (myInteger) para variables de ámbito local
• 2do (MyInteger) para propiedades públicas
• 4to (_myInteger) para variables privadas

Creo que la opción 4 es realmente la opción más legible. Le ayuda a tener que hacer esto:

public Person(string name, int age) 
{
    this.name = name;
    this.age = age;
}

También hace que todos los miembros privados sean más notorios. En el siguiente ejemplo, ¿de dónde ageviene el demonio ? Sin el thiscalificador es más difícil saberlo.

private void Method()
{
    var x = 2;
    var y = age + x;
}

Esto es mucho más fácil de entender:

private void Method()
{
    var x = 2;
    var y = _age + x;
}

En primer lugar, PascalCasing se reserva comúnmente para propiedades públicas, concursos, métodos, etc. de la clase. Entonces me saltaría 2 y 5.

En segundo lugar, se desaconseja la notación húngara en el mundo .NET, así que (creo que) 3 está listo. Asumiendo que eso es lo que está pasando con 3.

Eso se va con camelCasing y _camelCasing. Por lo general, uso _camelCasing para las variables de clase, y el viejo camelCasing para las variables con un alcance o un método más estrecho. La carcasa de camello es el estándar aceptado utilizado para argumentos de métodos, nombres de variables protegidas / privadas y variables dentro de un método o alcance más limitado.

También me gusta anteponer el guión bajo para que mis variables privadas se agrupen en mi inteligencia. Sin embargo, solo hago esto para las variables con alcance a un tipo. Variables declaradas dentro de un método o alcance más estrecho Dejo el subrayado desactivado. Facilita mantenerlos separados y mantener juntas las variables menos utilizadas.

private int integer

Si se confunde entre las variables miembro y locales en el alcance de un método, probablemente necesite refactorizar.

Creo que la mejor manera de hacerlo (en C # /. Net de todos modos) es una combinación de 2 y 6:

private int MyInteger { get; set; }

Teóricamente no hay ninguna variable aquí, pero se ve y actúa como una variable de instancia privada. Si necesitamos agregar algo de lógica de negocios a ese valor (es un valor completamente interno, por lo que podemos hacer lo que queramos después de todo), entonces ya está 'propiedad' para nosotros. ¡Una taza de victoria humeante!

Hago la opción # 4 porque así es como se ve el SSCLI, pero honestamente no me importa mucho nombrar variables privadas. Público es una historia diferente.

Por cierto, olvidaste m_MyInteger

¡No lo llamaría "mi" nada!

Pero yo diría

class C
{
     int VariableName { get; set; }
}

bastante a menudo esto es mejor que tener variables explícitas. Si tuviera una variable privada explícita la llamaríaint _variableName;

En C ++ tiendo a usar _ ya que cambio mucho los editores, lo que no me permite ver si es privado.

Para C #, tiendo a dejar el _ ausente ya que Visual Studio me permite ver si es privado.

Tiendo a usar la forma Camel Case para hacer esto.

Yo uso 4 ( private int _myInteger;) porque:

private int myInteger;

Así es como nombro mis variables locales.

private int MyInteger;

Así es como yo llamo constantes.

private int mMyInteger;

Este no es el estilo C #.

private int _MyInteger;

Esto se ve extraño.

con el guion bajo

Bill Wagner explica por qué en Effective C # . Pero nunca nombraría un entero mi Entero , mejor algo como _age o _length. Incluir el TypeName en el nombre de la instancia es una práctica horrible. Los nombres deben explicarse por sí mismos y dado que C # es Type-Safe, los tipos se pueden encontrar en todo momento.

Debe dar un ejemplo más específico, pero:

private int count` private int badFileCount`private static readonly int ReconnectAttemptsLimit

Por cierto, obtienes todo esto GRATIS cuando instalas y comienzas a usar lo último y mejor MSFT Stylecop.

Voy por la opción 5: private int _MyFoo

Sin embargo, no veo ninguna ventaja competitiva real sobre _myFoo.

Use camelCasing para variables privadas como myInteger

Considere un precedente _si la variable es una copia de seguridad de una propiedad para reducir las confusiones -
Variable _myPropertypara la propiedadMyProperty

ReSharper nombra mis variables, no solo las mías, sino que todos los demás también lo hacen. Hay una gran cantidad de consistencia a través del proyecto.

El estándar de codificación IDesign C # de Juval Lowy es bastante popular. Este estándar recomienda prefijar las variables de miembros privados con "m_" (Opción 6). Eso es lo que hacemos en nuestro equipo.

private int m_myInteger;

La opción 4 ( _myInteger) es una variación aceptable de esta norma.

No me gustó la recomendación de MSDN ( myInteger), porque hace que sea difícil distinguir a un miembro privado de una variable local. Su recomendación, por supuesto, resuelve este problema al calificar a los miembros privados con this, lo que me parece redundante.