CA1500 против SA1309 - Какой выигрывает?

Question

Я приставлю, сказав, что я понимаю, что как Code Analysis, так и StyleCop означают как рекомендации, и многие люди решили игнорировать их в любом случае. Но, сказав это, я хотел бы посмотреть, что общего согласия в отношении этих двух правил.

Rule CA1500 говорит, что имена параметров и частные имена полей не совпадают.

Rule SA1309, с другой стороны, говорит, что не префикс элементов с подчеркиванием или «m_».

Это оставляет нам небольшие возможности для выделения частных полей поддержки из их соответствующих параметров. Возьмите эти примеры.

SA1309 жалуется:

class SomeClass 
{ 
    int _someField; 

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

CA1500 жалуется:

class SomeClass 
{ 
    int someField; 

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

Какие у меня есть варианты? Я не хочу делать частное поле поддержки PascalCase, потому что это (я считаю, довольно универсальное) соглашение для общедоступных полей/свойств. И я не хочу переименовывать один или другой, только ради разрешения двусмысленности.

Итак, я остался одним из двух вышеуказанных, что потребовало бы, чтобы я подавил одно из правил SA/CA.

Что вы, ребята, обычно делаете? И что еще более важно, что думают авторы этих правил (так как они не предоставляют альтернативных решений в их документации)?

Answer 1

Сворачиваем SA1309. Обоснование этого довольно слабое.

Наша команда считает, что хорошо принятая практика частных членов, начинающихся с подчеркивания, намного превосходит идею о том, что кто-то может использовать другой редактор кода, который никогда не случается в нашем магазине. Что касается обеспечения «немедленной дифференциации», подчеркивание также делает это.

Если у вас действительно есть разработчики, которые все еще используют «m_», хотя вам все равно нужно это проверить, вы можете написать быстрое правило только для этого.

Answer 2

Основываясь на том, что я видел от самой Microsoft, я говорю о победе CA1500.

Если вы посмотрите на BCL, большая часть кода префикс локальных полей с подчеркиванием.

Answer 3

Вот мое обычное решение:

class SomeClass 
{ 
    int SomeField{get;set;} 

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

Answer 4

Единственная альтернатива, которую я могу думать о том, что это похоже на то, что она удовлетворяет обоим правилам и что я на самом деле видел использованную в любом месте, - это что-то вроде следующего. Я сам не следую этому соглашению, поскольку это кажется неуклюжим.

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

Нет конфликта. Измените имя параметра.

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

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

Answer 6

Простой, используйте суффикс «Field» для частных полей, когда есть класс:

private Int32 counterField; 

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

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

И вы можете удовлетворить оба правила. Украшение ваших переменных любыми символами или венгерскими префиксами является племенным. Все могут найти правило, которое им не нравится в StyleCop или FXCop, но стандарт работает только тогда, когда все его используют. Преимущества автоматического скруббера кода намного перевешивают ваши собственные «художественные» вклады в язык.