我的意思是,我了解代码分析和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规则之一。
你们通常做什么?更重要的是,这些规则的作者认为您应该怎么做(因为它们的文档中都没有提供替代解决方案)?
我们关闭SA1309。其背后的理由相当薄弱。
我们的团队认为,以下划线开头的私人成员的良好做法远远超过了有人可能在代码上使用其他编辑器的想法,而这在我们的商店中永远不会发生。至于提供“立即分化”,下划线也是如此。
如果您确实有仍然使用“ m_”的开发人员,并且仍然需要检查,则可以为此编写一条快速规则。
这是我通常的解决方法:
class SomeClass
{
int SomeField{get;set;}
public SomeClass(int someField)
{
SomeField = someField;
}
}
根据我从Microsoft本身所看到的,我说CA1500胜出。
如果您查看BCL,则大多数代码都会在本地字段前加上下划线。
简单,有一个类时,将后缀“ Field”用于私有字段:
private Int32 counterField;
public Int32 Counter
{
get
{
return this.counterField;
}
set
{
if (this.counterField != value)
{
this.counterField = value;
this.OnPropertyChanged("Counter");
}
}
您可以同时满足这两个规则。用任何字符或匈牙利前缀装饰变量是部族的。每个人都可以在StyleCop或FXCop中找到自己不喜欢的规则,但是只有当每个人都使用它时,该标准才有效。自动代码清理器的好处远远超过您自己对语言的“艺术”贡献。
我能想到的唯一选择似乎可以满足这两个规则,并且我实际上已经看到在任何地方都使用了以下内容。我本人并不遵循这个约定,因为它看起来很笨拙。
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);
}
}
}
没有冲突。更改参数名称。
public class SomeClass
{
private int namedField { get; set; }
public SomeClass(int differentlyNamedField)
{
this.namedField = differentlyNamedField;
}
}