代码分析的目的是什么？何时需要使用它？

我听说过Visual Studio的代码分析，但从未使用过。我已经阅读了MSDN，但仍然不了解代码分析的实际用途。

它与StyleCop不一样吗？

在某个地方，还提到了FxCop。代码分析有什么区别？

我需要为每个项目使用代码分析吗？我的同事进行的代码审查是否不足？

什么是代码分析？

代码分析（以前是FxCop）是一种静态分析工具，它搜索可能指示源代码中有问题的常见模式。例如，如果IDisposable未正确处理实现的类的实例，则代码分析将发出警告：

private void DoSomething()
{
    var connection = new SqlConnection(...);
    this.ChangeSomeData(connection);
}

这是上一段代码的正确实现：

private void DoSomething()
{
    using (var connection = new SqlConnection(...))
    {
        this.ChangeSomeData(connection);
    }
}

与任何静态分析工具一样，代码分析旨在查找难以手动找到的模式（或很无聊）。例如，在前面的示例中，对于开发人员来说，检查他使用的任何类是否实现IDisposable（或者记住实现它的所有.NET Framework类）可能会很无聊。

哪些项目符合条件？

尽管它会受到误报的影响，但与任何静态分析工具一样，通常在不使用抑制的情况下将关键业务代码设为零警告通常是有益的。在Visual Studio中，可以将代码分析配置为在编译时运行。如果项目设置还指定将警告视为错误，则不会违反代码分析规则。

由于中型或大型项目的静态分析可能会花费一些时间，因此将其从开发人员的机器移至TFS构建服务器通常是个好主意。尽管在预提交期间运行代码分析不是一个好主意（与StyleCop不同），但它仍可以在内部版本上运行，如果发现警告，则失败。

对于非关键业务代码，可以从Visual Studio或命令行手动运行代码分析。可以在项目属性中细化检查和警告，以满足您的需求。例如，如果您的项目不打算本地化，则可以关闭全球化警告。

与StyleCop一样，从项目开始时就决定从代码分析中确定项目是否将零警告作为目标非常重要。在现有项目中引入它可能会很痛苦。

它与StyleCop有区别吗？

请注意，代码分析与StyleCop不同。第一个区别是代码分析适用于编译的程序集，而StyleCop适用于源代码本身。第二个（也是最重要的）区别是，代码分析将搜索可能指示错误的模式，而StyleCop只是强制执行样式规则，这是团队使用的一种简单约定。

对于不太熟悉该语言的初学者来说，代码分析也特别有用，因为它常常会导致“ Aha！”。片刻。例如，CA2105：数组字段不应为只读字段，这可能会导致某人发现，即使将数组标记为只读，也不会使其成为不可变的，因为没有什么禁止更改数组中的元素。StyleCop不会导致发现：知道字段以小写字母开头或本地呼叫应以开头没有什么有趣的事this。

即使代码分析和StyleCop都强制执行了某些规则（例如CA1707：标识符不应包含下划线，而SA1310：字段名称不得包含下划线），这两个工具是互补的，并且经常并排使用。

我们已经有代码审查

代码审查的存在并不是避免代码分析的原因。代码分析和StyleCop都非常擅长在代码检查之前自动查找内容。没有比花一些代码审查来指出可能会自动发现的样式问题或问题模式更糟糕的了。保留代码评论以查找有趣的内容。

另一个方面是，审阅者不一定善于发现由Code分析发现的问题。例如，IDisposable可以在一个位置创建一个类实现的实例，然后将其放置在另一个位置。审阅者需要一些时间才能找到它，而静态分析工具则只需数毫秒即可发现它。