CA1500 против SA1309 - кто победит?

Question

Я поставлю префикс, сказав, что я понимаю, что 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.

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

Answer 1

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

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

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

Answer 2

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

class SomeClass
{
    int SomeField{get;set;}

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

Answer 3

Исходя из того, что я видел у самих Microsoft, я говорю, что CA1500 выигрывает.

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

Answer 4

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

 private Int32 counterField;

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

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

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

Answer 5

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

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

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

Answer 6

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

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