对于任何 C# 开发人员来说，哪些是“必须遵循”的 FxCop 规则？

Which are the "must follow" FxCop rules for any C# developer?

提问by Vijesh VP

I'm planning to start using FxCop in one of our ongoing project. But, when i tried it with selecting all available rules, it looks like I have to make lots of changes in my code. Being a "team member" I can't right away start making these changes, like naming convention change etc. anyway i would like to start using FxCop with a minimal rule set and would gradually increase the rule set as we goes on. Can you suggest me some must have FxCop rules which i should start following. Or do you suggest any better approach?

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

Note: Most of my code is in C#.

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

回答by TraumaPony

The design and security rules are a good place to start.

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

回答by OregonGhost

In my opinion, do the following:

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

For any new project, follow all FxCop rules. You may want to disable some of them, since not everything will make sense for your project. For an existing project, follow the rules from these categories as a minimum set:

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

• Globalization
• Interoperability
• Security
• Performance
• Portability

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

Since these are typically only few rule violations in an existing project, compared to the other categories, but may improve the quality of your application. When these rules are clear, try to fix the following categories:

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

• Design
• Usage

• 设计
• 用法

Since these will make it easier for you to spot bugs that have to do with the violations, but you will have a large amount of violations in existing code.

由于这些将使您更容易发现与违规有关的错误，但您将在现有代码中发现大量违规。

Always sort the violations by level/fix category and start with the critical ones. Skip the warnings for now.

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

In case you didn't know, there's also StyleCop available from Microsoft, checking your code on the source level. Be sure to enable MSBuild integration during installation.

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

回答by Sklivvz

On our most important code:

关于我们最重要的代码：

• Treat warnings as errors (level 4)
• FxCop must pass 100% (no ignores generally allowed)
• Gendarmeused as a guideline (sometimes it conflicts with FxCop)

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

Believe it or not, FxCop teaches you a hell of a lot on how to write better code... great tool! So for us, all rules are equally important.

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

回答by Aaron Powell

We're a web shop so we drop the following rules:

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

• Anything with Interop (we don't support COM integration unless a client pays for it!)
• Key signing (web apps shouldn't need high security prilages)

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

Occationally we'll drop the rule about using higher frameworks in dependancies as some of our CMS's are still .NET 2.0, but that doesn't mean the DAL/ Business Layers can't be .NET 3.5 as long as you're not trying to return an IQueryable (or anything .NET 3, 3.5).

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

回答by Lex Li

I fully agree with Sklivvz. But for existing projects, you may clean up FxCop violations category by category.

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

From time to time, Gendarme accepts new rules that are quite useful. So you may use Gendarme besides.

有时，宪兵接受非常有用的新规则。所以你也可以使用宪兵。

回答by Jeff Yates

In our process, we enabled all the rules and then we have to justify any suppressions as part of our review process. Often, it's just not possible to fix the error in time-efficient manner with regards to deadlines or its an error raised in error (this sometimes occurs - especially if your architecture handles plug-ins via reflection).

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

We also wrote a custom rule for globalization to replace an existing one because we didn't want to globalize the strings passed to exceptions.

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

In general, I'd say it's best to try and adhere to all rules. In my current home project, I have four build configurations - one set that specify the CODE_ANALYSIS define and one set that don't. That way, I can see all the messages I have suppressed just by building a non-CODE_ANALYSIS configuration. This means that suppressed messages can be periodically reviewed and potentially addressed or removed as required.

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

What I'd like to do in the long-run is have a build step that analyzes the SuppressMessage attributes against the actual errors and highlights those suppressions that are no longer required, but that's not currently possible with my setup.

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

回答by Patrick from NDepend team

An alternative to FxCop would be to use the tool NDepend that lets write Code Rules over C# LINQ Queries (namely CQLinq). Disclaimer: I am one of the developers of the tool

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

More than 200 code rulesare proposed by default. Customizing existing rules or creating your own rules is straightforward thanks to the well-knownC# LINQ syntax.

超过200分的规则是默认设置的。由于众所周知的C# LINQ 语法，自定义现有规则或创建自己的规则非常简单。

NDepend overlaps with FxCop on some code rules, but proposes plenty of unique code rules. Here are a few rules that I would classify as must-follow:

NDepend 在一些代码规则上与 FxCop 重叠，但提出了大量独特的代码规则。以下是我将其归类为必须遵循的一些规则：

• Avoid decreasing code coverage by tests of types
• Avoid making complex methods even more complex (Source CC)
• Avoid transforming an immutable type into a mutable one
• Overrides of Method() should call base.Method()
• Avoid the Singleton pattern
• Types with disposable instance fields must be disposable
• Disposable types with unmanaged resources should declare finalizer
• Avoid namespaces mutually dependent
• Avoid namespaces dependency cycles
• UI layer shouldn't use directly DB types
• API Breaking Changes: Methods
• Complex methods partially covered by tests should be 100% covered
• Potentially dead Types
• Structures should be immutable
• Avoid naming types and namespaces with the same identifier

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

Notice that Rules can be verified live in Visual Studioand at Build Process time, in a generated HTML+javascript report.

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

回答by Jonathan Allen

Turn on one rule at a time. Fix or exclude any warnings it reports, then start on the next one.

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

回答by sthiers

Some of the rules avoid us bugs or leaks:

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

• Do not catch general exception types (May be the best rule for us. According to the case, it can be easy or difficult to enforce)
• Test for NaN correctly (easy to enforce)
• Disposable fields should be disposed (quite easy to enforce)
• Dispose should call base dispose (quite easy to enforce)
• Disposable types should declare finalizer (quite easy to enforce)

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

Some help us have a better design, but be careful, they may lead you to big refactoring when central API is impacted. We like

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

• Collection properties should be readonly (difficult to enforce in our case)
• Do not expose generic list
• member should not expose certain conrete types
• Review usuned parameters (Improves easily your API)

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

Someone on our project tried the performance ruleswith no improvement. (Actually, these rules are about micro-optimizing, which gives no result if no bottleneck identification shows microoptimizing is needed). I would suggest notstarting with these ones.

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

回答by sthiers

The minimal fxcop and also code analysis (if using VS2010 Premium or Ultimate) is the following: http://msdn.microsoft.com/en-us/library/dd264893.aspx

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