CA1500 vs. SA1309 - Quale si vince?

Question

Mi prefisso dicendo che capisco che sia Code Analysis che StyleCop sono intesi come linee guida, e molte persone hanno scelto di ignorarli comunque. Ma detto questo, mi piacerebbe vedere quale sia il consenso generale riguardo a queste due regole.

Rule CA1500 dice non rendere i nomi dei parametri e i nomi di campi privati ​​uguali.

Rule SA1309, d'altra parte, non anteporre prefissi ai membri con trattino basso o "m_".

Questo ci lascia poche opzioni per distinguere i campi di backing privati ​​dai parametri corrispondenti. Prendi questi esempi.

SA1309 si lamenta:

class SomeClass 
{ 
    int _someField; 

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

CA1500 si lamenta:

class SomeClass 
{ 
    int someField; 

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

Quali opzioni ho? Non voglio rendere il campo di supporto privato PascalCase, perché questa è la convenzione (credo abbastanza universale) per campi/proprietà pubblici. E non voglio rinominare l'uno o l'altro, solo per il gusto di risolvere l'ambiguità.

Quindi mi rimane uno dei due precedenti, il che richiederebbe la soppressione di una delle regole SA/CA.

Cosa fate tipicamente voi ragazzi? E, cosa più importante, cosa pensano che dovresti fare gli autori di queste regole (dato che non forniscono soluzioni alternative nella loro documentazione)?

Answer 1

Noi spegnere SA1309. Il ragionamento dietro è abbastanza debole.

Il nostro team ritiene che la pratica ben accettata dei membri privati ​​che iniziano con i trattini bassi superi di gran lunga l'idea che qualcuno possa utilizzare un editor diverso nel codice, che comunque non accade mai nel nostro negozio. Per quanto riguarda la "differenziazione immediata", anche il trattino basso lo fa.

Se davvero gli sviluppatori usano ancora "m_" e se è ancora necessario verificarlo, è possibile scrivere una regola rapida per questo.

Answer 2

Sulla base di ciò che ho visto da Microsoft, dico che vince CA1500.

Se si guarda il BCL, la maggior parte del codice prefigura i campi locali con un trattino basso.

Answer 3

Qui è la mia solita soluzione:

class SomeClass 
{ 
    int SomeField{get;set;} 

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

Answer 4

L'unica alternativa che riesco a pensare sembra che soddisfi entrambe le regole e che in realtà ho visto usato ovunque sia qualcosa di simile al seguente. Non seguo personalmente questa convenzione, perché mi sembra goffo.

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

Non c'è conflitto. Cambia il nome del parametro.

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

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

Answer 6

semplice, utilizzare il suffisso 'campo' per i campi privati ​​quando c'è una classe:

private Int32 counterField; 

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

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

e si può soddisfare entrambe le regole. Decorare le tue variabili con qualsiasi carattere o prefisso ungherese è tribale. Tutti possono trovare una regola che non gli piace in StyleCop o FXCop, ma uno standard funziona solo quando tutti lo usano. I vantaggi di uno scrubber automatico di codice superano di gran lunga i tuoi personali contributi "artistici" alla lingua.