对源代码进行静态代码分析有什么好处？我在和FxCop玩耍，我想知道除了确保我们遵循编码标准之外，是否还有其他好处？

解决方案

实际上，fxcop并不能特别遵循编码标准。它可以设计一个经过深思熟虑的框架/ API。确实，部分编码标准(例如公共成员的大写字母)将被FxCop捕获，但是编码标准并不是重点。

可以使用stylecop来检查编码标准，stylecop可以像fxcop一样检查源代码，而不是MSIL。

它可以捕获实际的错误，例如忘记处理IDisposables。

许多类型的内存泄漏和常见逻辑错误也可以静态捕获。我们还可以查看循环复杂度等，它们可能是我们提到的"编码标准"的一部分，但可能是用于评估代码的算法"整洁度"的单独指标。

在任何情况下，只有将分析(动态或者运行时分析)与静态分析/毛发进行明智的组合，才能确保代码一致，可靠。哦，那还有一点运气;-)

取决于规则，但是可以避免许多细微的缺陷，可以清除代码，可以检测到潜在的性能问题等。

用一种方法来描述...如果它便宜或者免费(在时间和财务成本上)并且没有破坏任何东西，为什么不使用它呢？

有各种好处：

• 如果代码中包含反模式，则可能会被警告。
• 有某些指标(例如McCabe的Cyclomatic Complexity)可以告诉我们有关源代码的有用信息。
• 我们还可以从静态分析中获得出色的东西，例如调用图和类图。如果我们要攻击新的代码库，那就太好了。

看看SourceMonitor

这是一个权衡。对于想提高对框架和准则的理解的个人开发人员，我绝对会鼓励这样做。 FxCop会产生很多噪音/误报，但我还发现了以下好处：

• 它会检测到错误(例如，有关未使用的参数的警告可能表明我们在方法主体中使用了错误的参数)。
• 了解FxCop遵循的准则可成为更好的开发人员。

但是，在具有混合能力团队的情况下，FxCop可能会产生太多的误报而无用。初级开发人员将很难理解FxCop抛出的一些更深奥的违规行为是否应该引起他们的关注或者仅仅是噪音。

底线：

• 如果我们正在开发可重用的类库(例如内部框架)，请确保我们拥有良好的开发人员并使用FxCop。
• 对于具有混合功能团队的日常应用程序开发，这可能不可行。

FxCop中有所有警告的列表。我们可以看到以下方面的警告：

Design Warnings
  
  Warnings that support proper library
  design as specified by the .NET
  Framework Design Guidelines.
  
  Globalization Warnings
  
  Warnings that support world-ready
  libraries and applications.
  
  Interoperability Warnings
  
  Warnings that support interacting with
  COM clients.
  
  Naming Warnings
  
  Warnings that support adherence to the
  naming conventions of the .NET
  Framework Design Guidelines.
  
  Performance Warnings
  
  Warnings that support high performance
  libraries and applications.
  
  Security Warnings
  
  Warnings that support safer libraries
  and applications.

根据应用程序的一些这样的地区可能不是很有趣，但如果你如需要COM互操作性，这些测试确实可以避免陷阱。

其他静态检查工具可以检测错误，例如不处理IDisposable，内存泄漏和其他细微的错误。在极端情况下，请参见尚未发布的NStatic工具。

NStatic is used to track things such as redundant parameters, expressions that evaluate to constants, infinite loops and many other metrics.