我的前缀是说我明白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规则。
你们通常做什么?更重要的是,这些规则的作者认为你应该做些什么(因为它们都没有在他们的文档中提供替代解决方案)?
答案 0 :(得分:22)
我们关闭SA1309。背后的原因相当薄弱。
我们的团队认为,以下划线开头的私人会员广泛接受的做法远远超过了某人可能在代码上使用不同编辑器的想法,这在我们的商店中从未发生过。至于提供“直接区分”,下划线也是如此。
如果你真的让开发人员仍然使用“m_”而你仍然需要检查它,你可以为此编写一个快速规则。
答案 1 :(得分:3)
这是我通常的解决方案:
class SomeClass
{
int SomeField{get;set;}
public SomeClass(int someField)
{
SomeField = someField;
}
}
答案 2 :(得分:2)
根据我从微软自己看到的情况,我说CA1500胜出。
如果查看BCL,大多数代码都会在本地字段前加下划线。
答案 3 :(得分:0)
简单,使用后缀' Field'对于私人领域,当有一个班级时:
private Int32 counterField;
public Int32 Field
{
get
{
return this.counterField;
}
set
{
if (this.counterField != value)
{
this.counterField = value;
this.OnPropertyChanged("Counter");
}
}
你可以满足这两个规则。使用任何字符或匈牙利语前缀来装饰变量都是部落的。每个人都可以在StyleCop或FXCop中找到他们不喜欢的规则,但只有每个人都使用它时,标准才有效。自动代码清理程序的好处远远超过您自己的个人艺术品#39;对语言的贡献。
答案 4 :(得分:-1)
我能想到的唯一选择似乎是满足这两个规则并且我实际上在任何地方看到的都是如下所示。我自己并不遵循这个惯例,因为它看起来很笨拙。
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);
}
}
}
答案 5 :(得分:-2)
没有冲突。更改参数名称。
public class SomeClass
{
private int namedField { get; set; }
public SomeClass(int differentlyNamedField)
{
this.namedField = differentlyNamedField;
}
}