28

我计划在我们正在进行的项目之一中开始使用 FxCop。但是，当我尝试选择所有可用规则时，看起来我必须对我的代码进行大量更改。作为“团队成员”，我不能立即开始进行这些更改，例如更改命名约定等。无论如何，我想开始使用具有最小规则集的 FxCop，并随着我们的继续而逐渐增加规则集。你能建议我一些必须有我应该开始遵循的 FxCop 规则吗？或者你有什么更好的方法吗？

注意：我的大部分代码都是用 C# 编写的。

4

10 回答 10

12

在我们最重要的代码上：

  • 将警告视为错误（级别 4）
  • FxCop 必须通过 100%（通常不允许忽略）
  • 宪兵作为指导方针（有时与 FxCop 冲突）

信不信由你，FxCop 会教你很多关于如何编写更好的代码的知识……很棒的工具！所以对我们来说，所有规则都同等重要。

于 2008-09-27T08:58:13.627 回答
8

在我看来，请执行以下操作：

对于任何新项目，请遵守所有 FxCop 规则。您可能想要禁用其中的一些，因为并非所有内容都对您的项目有意义。对于现有项目，请遵循以下类别中的规则作为最低限度：

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

由于与其他类别相比，这些通常只是现有项目中的少数违规行为，但可能会提高您的应用程序的质量。当这些规则明确时，尝试修复以下类别：

  • 设计
  • 用法

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

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

如果您不知道，Microsoft 还提供 StyleCop，可在源代码级别检查您的代码。请务必在安装期间启用 MSBuild 集成。

于 2008-09-27T08:38:07.060 回答
4

一些规则避免了我们的错误或泄漏：

  • 不要捕获一般的异常类型（对我们来说可能是最好的规则。根据情况，执行起来可能容易或困难）
  • 正确测试 NaN（易于实施）
  • 一次性字段应该被处理（很容易执行）
  • Dispose 应该调用 base dispose （很容易执行）
  • 一次性类型应该声明终结器（很容易执行）

有些帮助我们有更好的设计，但要小心，当中心 API 受到影响时，它们可能会导致你进行大规模的重构。我们喜欢

  • 集合属性应该是只读的（在我们的例子中很难强制执行）
  • 不要暴露通用列表
  • 成员不应公开某些具体类型
  • 查看使用的参数（轻松改进您的 API）

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

于 2010-01-27T10:56:08.280 回答
2

最小的 fxcop 和代码分析（如果使用 VS2010 Premium 或 Ultimate）如下：http: //msdn.microsoft.com/en-us/library/dd264893.aspx

于 2010-12-14T15:12:32.987 回答
2

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

于 2008-12-18T17:14:51.737 回答
2

FxCop 的替代方法是使用 NDepend 工具，该工具允许在 C# LINQ 查询（即 CQLinq）上编写代码规则。免责声明：我是该工具的开发人员之一

默认提出超过200 条代码规则。借助众所周知的C# LINQ 语法，自定义现有规则或创建自己的规则非常简单。

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

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

于 2008-12-18T16:52:06.070 回答
1

我们是一家网上商店，所以我们放弃了以下规则：

  • 任何与 Interop 相关的东西（除非客户付费，否则我们不支持 COM 集成！）
  • 密钥签名（Web 应用程序不应该需要高安全性）

有时我们会放弃在依赖项中使用更高框架的规则，因为我们的一些 CMS 仍然是 .NET 2.0，但这并不意味着只要您不尝试，DAL/业务层就不能是 .NET 3.5返回 IQueryable（或任何 .NET 3、3.5）。

于 2008-09-27T09:04:45.187 回答
1

在我们的流程中，我们启用了所有规则，然后我们必须证明任何禁止行为是我们审查流程的一部分。通常，就截止日期或错误引发的错误（有时会发生这种情况 - 特别是如果您的架构通过反射处理插件时）以省时的方式修复错误是不可能的。

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

一般来说，我会说最好尝试遵守所有规则。在我当前的家庭项目中，我有四个构建配置 - 一组指定 CODE_ANALYSIS 定义，一组不指定。这样，我可以通过构建非 CODE_ANALYSIS 配置来查看我抑制的所有消息。这意味着可以定期查看被抑制的消息，并可能根据需要对其进行处理或删除。

从长远来看，我想做的是有一个构建步骤，根据实际错误分析 SuppressMessage 属性并突出显示不再需要的那些抑制，但我的设置目前无法做到这一点。

于 2008-09-28T18:13:56.027 回答
0

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

于 2008-09-27T08:34:24.917 回答
0

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

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

于 2008-09-27T10:05:19.360 回答