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规则。
你们通常做什么？ 更重要的是，这些规则的作者认为你应该做些什么（因为它们都没有在他们的文档中提供替代解决方案）？
我们关掉了SA1309。 背后的原因相当薄弱。
我们的团队认为，以下划线开头的私人会员广泛接受的做法远远超过了某人可能在代码上使用不同编辑器的想法，这在我们的商店中从未发生过。 至于提供“直接区分”，下划线也是如此。
如果你真的让开发人员仍然使用“m_”而你仍然需要检查它，你可以为此编写一个快速规则。
这是我通常的解决方案：
class SomeClass { int SomeField{get;set;} public SomeClass(int someField) { SomeField = someField; } }
根据我从微软自己看到的情况，我说CA1500胜出。
如果查看BCL，大多数代码都会在本地字段前加下划线。
很简单，当有一个类时，对私有字段使用后缀’Field’：
private Int32 counterField; public Int32 Field { 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; } }