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