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

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

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

Правило SA1309, с другой стороны, гласит, что не следует добавлять к членам префикс подчеркивания или "м_".

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

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.

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


person Jerad Rose    schedule 09.07.2010    source источник
comment
ваш первый пример не компилируется, имена перепутаны :)   -  person µBio    schedule 09.07.2010
comment
Обычно я нарушаю CA1500. Но у меня только Pro, без TFS, поэтому я никогда не вижу предупреждения. :)   -  person Stephen Cleary    schedule 09.07.2010
comment
Я постоянно нарушаю CA1500, но до сих пор не получал предупреждения, хотя CA1500 включен. Есть ли что-то волшебное в этом правиле?   -  person Albic    schedule 09.07.2010
comment
@Albic - То же самое, кажется, мы только начали получать предупреждение. И мы всегда шли по пути второго примера. Недавно мы перешли с FxCop 1.36 на анализ кода в VS2010, но я не думаю, что это новое правило. Я не уверен.   -  person Jerad Rose    schedule 09.07.2010


Ответы (6)


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

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

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

person womp    schedule 09.07.2010
comment
Спасибо, это кажется наиболее логичным подходом. - person Jerad Rose; 09.07.2010

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

class SomeClass
{
    int SomeField{get;set;}

    public SomeClass(int someField)
    {
        SomeField = someField;
    }
}
person µBio    schedule 09.07.2010
comment
Я также использую автоматически реализуемые свойства, когда это возможно (что чаще всего), но бывают случаи, когда у меня есть частные поля, не раскрывая их как общедоступные свойства. - person Jerad Rose; 09.07.2010

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

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

person Justin Niessner    schedule 09.07.2010
comment
Но это старый код? Соглашения были изобретены, когда был написан BCL. - person Stephen Cleary; 09.07.2010
comment
и я читал код в BCL, который я бы наказал программистам за написание ... :) Просто скажу: просто потому, что кто-то внутри Microsoft это делает, это не значит, что это правильно - или даже рекомендовано Microsoft в целом. - person Stephen Cleary; 09.07.2010
comment
@ Стивен Клири - Я тоже так думал. Я вижу очень непоследовательные практики, и стараюсь не использовать их код как святой Грааль лучших практик. - person Jerad Rose; 09.07.2010
comment
StyleCop превосходит стиль BCL или Framework Design Guidelines. В основном код BCL и книга были написаны разработчиками C ++, и они сохраняют согласованный стиль внутри BCL. StyleCop предназначен для C #. C # с годами выработал свой собственный стиль, и StyleCop это отражает. blogs.msdn.com/ б / sourceanalysis / archive / 2008/05/25 / - person AllenSanborn; 17.08.2011

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

 private Int32 counterField;

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

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

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

person Quarkly    schedule 22.01.2015

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

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);
        }
    }
}
person Dr. Wily's Apprentice    schedule 09.07.2010
comment
Это нарушит SA1305 «FieldNamesMustNotUseHungarianNotation». Эта ссылка показывает, как изменить StyleCop, чтобы разрешить определенные префиксы. Содержимое также находится в справке StyleCop. - person AllenSanborn; 17.08.2011
comment
Там же. Использование буквы «м» такое же племенное, как и «_». Прекратите пытаться определить свой собственный язык. - person Quarkly; 21.02.2015

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

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

    public SomeClass(int differentlyNamedField)
    {
        this.namedField = differentlyNamedField;
    }
}
person frattaro    schedule 05.03.2014
comment
Не уверен, почему голоса против. Два правила в вопросе совершенно не противоречат друг другу. Любой другой ответ будет «в первую очередь основанным на мнении», что потребует закрытия вопроса в связи с этим фактом. - person frattaro; 21.09.2017