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

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

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

Правило 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.

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

Ответ 1

Мы выключаем SA1309. Причины этого довольно слабы.

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

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

Ответ 2

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

class SomeClass
{
    int SomeField{get;set;}

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

Ответ 3

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

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

Ответ 4

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

 private Int32 counterField;

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

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

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

Ответ 5

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

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);
        }
    }
}

Ответ 6

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

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

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