我计划在我们正在进行的项目之一中开始使用FxCop。但是，当我尝试选择所有可用规则时，似乎必须对代码进行大量更改。作为"团队成员"，我不能马上开始进行这些更改，例如命名约定更改等。无论如何，我想开始使用带有最小规则集的FxCop，并随着我们的进行逐渐增加规则集。我们能建议我一些必须具有FxCop规则的我应该开始遵循的规则。还是我们建议任何更好的方法？

注意：我的大部分代码都在C＃中。

解决方案

设计和安全规则是一个很好的起点。

我认为，请执行以下操作：

对于任何新项目，请遵循所有FxCop规则。我们可能要禁用其中的一些，因为并非所有项目都对项目有意义。
对于现有项目，请至少遵循以下类别中的规则：

• 全球化
• 互通性
• 安全
• 表现
• 可移植性

与其他类别相比，由于这些通常仅是现有项目中很少违反规则的行为，因此可以提高应用程序的质量。明确这些规则后，请尝试修复以下类别：

• 设计
• 用法

因为这些将使我们更容易发现与违规有关的错误，但是在现有代码中将有大量违规。

始终按级别/修复程序类别对违规进行排序，并从严重违规开始。暂时跳过警告。

如果我们不知道，Microsoft还可提供StyleCop，在源代码级别检查代码。确保在安装过程中启用MSBuild集成。

在我们最重要的代码上：

• 将警告视为错误(级别4)
• FxCop必须通过100％(通常不允许忽略)
• 宪兵用作指导(有时与FxCop冲突)

信不信由你，FxCop会教我们很多有关如何编写更好的代码的技巧...很棒的工具！因此，对我们而言，所有规则都同样重要。

我们是一家网上商店，因此我们删除了以下规则：

• 与Interop兼容(除非客户付费，否则我们不支持COM集成！)
• 密钥签名(Web应用程序不需要高安全性)

有时，由于某些CMS仍是.NET 2.0，我们将放弃在依赖关系中使用更高框架的规则，但这并不意味着DAL /业务层就不能成为.NET 3.5，只要我们不尝试。返回一个IQueryable(或者任何.NET 3、3.5)。

我完全同意Sklivvz。但是对于现有项目，我们可以按类别清理FxCop违规行为。

宪兵不时接受非常有用的新规则。因此，我们还可以使用Gendarme。

在我们的流程中，我们启用了所有规则，然后在审核过程中必须对所有抑制作辩护。通常，就期限或者错误引起的错误而言，不可能以省时的方式解决错误(有时会发生这种错误(尤其是在体系结构通过反射处理插件的情况下)。

我们还为全球化编写了一个自定义规则，以替换现有规则，因为我们不想对传递给异常的字符串进行全球化。

总的来说，我想最好是遵守所有规则。在当前的家庭项目中，我有四种构建配置，一组指定CODE_ANALYSIS定义，而另一组没有。这样，仅通过构建非CODE_ANALYSIS配置，我就可以看到所有我抑制的消息。这意味着可以定期查看被抑制的消息，并根据需要潜在地解决或者删除它们。

从长远来看，我想做的是一个构建步骤，该分析步骤将SuppressMessage属性与实际错误进行比较，并突出显示不再需要的那些抑制，但是目前我的设置无法实现这些抑制。

FxCop的替代方法是使用工具NDepend，该工具可以通过CLINQ查询(即CQLinq)编写代码规则。免责声明：我是该工具的开发人员之一

默认情况下，建议使用200多个代码规则。借助众所周知的CLINQ语法，自定义现有规则或者创建自己的规则非常简单。

NDepend在某些​​代码规则上与FxCop重叠，但是提出了许多独特的代码规则。以下是一些我必须遵循的规则：

• 避免通过类型测试来减少代码覆盖率
• 避免使复杂的方法变得更加复杂(Source CC)
• 避免将不可变类型转换为可变类型
• Method()的重写应调用base.Method()
• 避免单例模式
• 具有一次性实例字段的类型必须是一次性的
• 具有非托管资源的一次性类型应声明终结器
• 避免名称空间相互依赖
• 避免名称空间依赖周期
• UI层不应直接使用数据库类型
• API重大更改：方法
• 测试部分涵盖的复杂方法应100％涵盖
• 潜在死亡的类型
• 结构应该是不变的
• 避免使用相同的标识符命名类型和名称空间

请注意，可以在生成的HTML + javascript报告中在Visual Studio中以及构建过程中实时验证规则。

一次启用一个规则。修复或者排除它报告的任何警告，然后从下一个警告开始。

一些规则可以避免我们的错误或者泄漏：

• 不要捕获一般的异常类型(对我们来说可能是最好的规则。根据情况，执行起来可能很容易，也可能很难。)
• 正确测试NaN(易于执行)
• 应处理一次性字段(非常容易执行)
• 处置应称为基础处置(相当容易执行)
• 一次性类型应声明终结器(相当容易执行)

有些方法可以帮助我们设计更好，但请注意，当中央API受到影响时，它们可能会导致我们进行大量重构。我们喜欢

• 集合属性应为只读(在我们的案例中很难执行)
• 不公开通用列表
• 成员不应公开某些具体类型
• 查看常用的参数(轻松改进API)

我们项目中的某人尝试了性能规则，但没有任何改进。 (实际上，这些规则是关于微优化的，如果没有瓶颈识别表明需要进行微优化，则不会产生任何结果)。我建议不要从这些开始。

最小的fxcop和代码分析(如果使用VS2010 Premium或者Ultimate)如下：http://msdn.microsoft.com/zh-cn/library/dd264893.aspx