c# - CA1500 vs. SA1309-¿Cuál gana?

naming-conventions code-analysis

Question

Prefijo diciendo que entiendo que tanto el Análisis de Código como el StyleCop están pensados ​​como directrices, y muchas personas decidieron ignorarlos de todos modos. Pero dicho esto, me gustaría ver cuál es el consenso general con respecto a estas dos reglas.

La regla CA1500 dice que no haga que los nombres de los parámetros y los nombres de los campos privados sean iguales.

La regla SA1309 , por otro lado, dice que no prefija a los miembros con subrayado o "m_".

Esto nos deja con pocas opciones para distinguir los campos de respaldo privados de sus parámetros correspondientes. Tomemos estos ejemplos.

SA1309 se queja:

class SomeClass
{
    int _someField;

    public SomeClass(int someField)
    {
        this._someField = someField;
    }
}

CA1500 se queja:

class SomeClass
{
    int someField;

    public SomeClass(int someField)
    {
        this.someField = someField;
    }
}

¿Que opciones tengo? No quiero hacer que el campo de respaldo privado sea PascalCase, porque esta es la convención (creo que bastante universal) para los campos / propiedades públicos. Y no quiero cambiar el nombre de uno u otro, solo para resolver la ambigüedad.

Así que me quedo con uno de los dos anteriores, lo que me obligaría a suprimir una de las reglas de SA / CA.

¿Qué suelen hacer ustedes? Y lo que es más importante, ¿qué piensan los autores de estas reglas que debe hacer (ya que ninguno de los dos proporciona soluciones alternativas en su documentación)?

Answer 1

Apagamos el SA1309. El razonamiento detrás de esto es bastante débil.

Nuestro equipo considera que la práctica bien aceptada de los miembros privados que comienzan con un subrayado supera con creces la idea de que alguien pueda usar un editor diferente en el código, lo que nunca sucede en nuestra tienda. En cuanto a proporcionar una "diferenciación inmediata", el subrayado hace eso también.

Si realmente tienes desarrolladores que aún usan "m_" y aún necesitas verificar eso, podrías escribir una regla rápida para eso.

Answer 2

Aquí está mi solución habitual:

class SomeClass
{
    int SomeField{get;set;}

    public SomeClass(int someField)
    {
        SomeField = someField;
    }
}

Answer 3

Basándome en lo que he visto de Microsoft, digo que CA1500 gana.

Si observa el BCL, la mayoría de los códigos prefijan los campos locales con un guión bajo.

Answer 4

La única alternativa en la que puedo pensar que parece que satisfaría ambas reglas y que en realidad he visto utilizada en cualquier lugar es algo como lo siguiente. Yo no sigo esta convención, ya que parece torpe.

public class Class1
{
    // prefix private fields with "m"
    private int mValue1;

    public int Value1
    {
        get { return mValue1; }
        set { mValue1 = value; }
    }

    private string mValue2;

    public string Value2
    {
        get { return mValue2; }
        set { mValue2 = value; }
    }

    // prefix parameters with "p"
    public bool PerformAction(int pValue1, string pValue2)
    {
        if (pValue1 > mValue1)
        {
            mValue2 = pValue2;
            return true;
        }
        else
        {
            return (mValue2 == pValue2);
        }
    }
}

Answer 5

No hay conflicto. Cambia el nombre del parámetro.

public class SomeClass
{
    private int namedField { get; set; }

    public SomeClass(int differentlyNamedField)
    {
        this.namedField = differentlyNamedField;
    }
}

Answer 6

Simple, use el sufijo ''Campo'' para campos privados cuando haya una clase:

 private Int32 counterField;

 public Int32 Field
 {
     get
     {
          return this.counterField;
     }

     set
     {
           if (this.counterField != value)
           {
                this.counterField = value;
                this.OnPropertyChanged("Counter");
            }
      }

Y puedes cumplir ambas reglas. Decorar tus variables con cualquier carácter o prefijo húngaro es tribal. Todos pueden encontrar una regla que no les gusta en StyleCop o FXCop, pero una norma solo funciona cuando todos la usan. Los beneficios de un depurador automático de código superan con creces sus propias contribuciones "artísticas" personales al idioma.