C# StyleCop疯狂：保护域

我被委托尽可能使其他人的代码符合某些StyleCop规则集。。现在我想知道以下情况：

我有一个包含字段的抽象类

protected double[] coefficients;

Stylecop说：SA1401:必须使用私有访问声明字段。使用属性公开字段

所以我把它改成：

protected double[] coefficients { get; set; } 

Stylecop说：SA1300：属性名称以大写字母开头：系数

因为它是一个抽象类，所以子类是我无法控制的。它们使用父类字段

base.coverties

。。嗯

---

所以。。除了抑制（或禁用）此警告之外，没有其他方法可以消除此警告，对吗T

如果将字段更改为属性，则派生类（来自其他已编译程序集）将找不到“系数”，因为属性是两个方法的快捷方式-不等于字段

---

如果您必须保持与其他程序集的兼容性，那么兼容性必须是首要目标，而StyleCop规则则是次要目标。

事实上，您没有

如果您想在以后的代码版本中将其清除，可以将

coverties

属性设置为deprecated，并提供一条消息，说明此属性将在任何后续版本的代码中删除

在当前版本中：

private double[] _coefficients;

// Using this property will produce a compile-time warning.
[Obsolete("coefficients will be removed in future versions. Use Coefficients instead.")]
protected double[] coefficients 
{ 
    get { return _coefficients; } 
    set { _coefficients = value; } 
}

protected double[] Coefficients 
{ 
    get { return _coefficients; } 
    set { _coefficients = value; } 
}

在以后的版本中：

private double[] _coefficients;

// Using this property will produce a compile-time error.
[Obsolete("coefficients was removed. Use Coefficients instead.", true)]
protected double[] coefficients 
{ 
    get { return _coefficients; } 
    set { _coefficients = value; } 
}

protected double[] Coefficients 
{ 
    get { return _coefficients; } 
    set { _coefficients = value; } 
}

---

甚至将字段更改为属性也是一个潜在的破坏性更改。如果您必须保持与无法控制的已编译二进制文件的兼容性，我甚至不建议进行第一次更改

关于StyleCop，您必须记住的一点是，它固执地坚持您遵循编码指导原则，这实际上与规则不同。你遇到的两个准则都非常合理。在编写新代码时，我总是遵循它们。你也应该。然而，如果像您的情况一样，兼容性更重要，那么可以忽略StyleCop的坚持

即使您要解决当前警告，下一件事可能会让您感到震惊（或者如果它没有，它和FxCop肯定会捕捉到这一点），那就是数组永远不应该作为接口的一部分公开（即标记为

受保护的
或
公共的
）。相反，您应该公开类似于
IEnumerable
、
IList
或
ReadOnlyCollection
的内容

冲洗，起泡，重复。如果你真的不能修改代码，那你就是在追你的尾巴

为了看看我是否能让你更疯狂，我会注意到，如果发现子类显式地调用父类上的成员，如果它们不重写该成员本身的实现，那么FxCop会引发一场冲突。所以基本上，
base.coverties
一开始就不是no。如果你遵循所有的指导原则，它会使你更容易遵循。当然，合乎逻辑的推论是，如果你没有遵循所有的指导原则，那么遵循这些指导原则就会变得更加困难。
是的。嗯，到目前为止，我通常能够判断是否有可能更改某些内容以使其符合要求。例如间距、私有变量等-我只是不确定我是否太快地宣布这个案例“无法解决”。嗯。。。你能详细说明一下吗？Florian的解决方案似乎适用于我的单元测试。如果您使用已编辑的源代码重新编译单元测试，就不会有问题。更改field->property的问题只是，如果依赖代码已经编译并且无法重新编译。非常感谢。。。虽然在其他人的评论之后，我可能会压制这个警告，然后再处理它是的，当然，我的答案只适用于你真的需要修复的情况：）但这段代码会让你直接陷入FxCop冲突，因为你的成员只是大小写不同：）修复一个，得到一个。至少它是平衡的：）实用的观点是非常值得赞赏的。正确看待指导方针是很好的。