在存在违规情况的现有代码库上执行FxCop /静态分析时，会使用哪些策略？如何最有效地减少静态分析违规？

解决方案

回答

用一种流传的风格重写代码！

严重的是，一个旧的代码库将有数百个错误，但这就是为什么我们有新手/实习程序员。纠正FxCop违规是获得代码库概述并学习如何编写符合标准的.NET代码的好方法。

因此，只需硬着头皮，喝很多咖啡因，然后几天就可以解决它！

回答

首先要充分利用[SuppressMessage]属性。至少在开始时。通过该属性将计数计数为0后，我们便应遵循以下规则：新签入操作不得引入FxCop违规行为。

Visual Studio 2008具有出色的代码分析功能，使我们可以确保代码分析可以在每个版本上运行，并且可以将警告视为错误。这可能会使速度变慢，因此我建议设置一个持续集成服务器(如CruiseControl.NET)，并在每个签入中运行代码分析。

一旦控制好它，并且不会在每次签入中引入新的违规行为，就开始一次解决整个FxCop违规类，目标是删除我们使用的SuppressMessageAttributes。

跟踪我们真正想要保留的那些值的方法是始终向我们真正想要抑制的那些值添加一个Justification值。

回答

NDepend看起来可以完成我们要做的事情，但是我不确定是否可以将其集成到CruiseControl.Net自动构建中，如果代码不符合要求，构建将失败(这就是我所要做的) d想发生)。

还有其他想法吗？

回答

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

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

为了使假阳性的数量保持较低，CQLinq提供了独特的功能，可以通过以notmycode为前缀的特殊代码查询来定义JustItCode的集合。有关此功能的更多说明，请参见此处。例如，以下是两个notmycode默认查询：

• 丢弃JustMyCode生成的设计器方法
• 丢弃JustMyCode生成的类型

为了降低错误肯定的数量，使用CQLinq，我们还可以将规则结果仅集中在添加的代码或者重构的代码上，因为过去定义了基线。请参阅以下规则，以检测自基线以来添加或者重构的方法过于复杂的方法：

warnif count > 0 
from m in Methods
where m.CyclomaticComplexity > 20 &&
      m.WasAdded() || m.CodeWasChanged()
select new { m, m.CyclomaticComplexity }

最后，请注意，使用NDepend代码规则可以在Visual Studio中实时生成，并在生成过程中在生成的HTML + javascript报告中进行验证。