在构建时运行代码分析和StyleCop

引言

代码审查是一件好事。

引用

在一个复杂的程序中，架构指南赋予程序结构平衡，而构建指南提供底层和谐…… 如果没有统一的规范，你的作品将是一堆风格上的草率变化。 成功编程的关键之一是避免任意变化，以便你的大脑可以自由地专注于真正需要的变化。 --  Steve McConell

如果使用 .Net 编程，最好的选择是遵循 MS 内部使用的 .Net 编码标准。 此编码标准记录在一本书中 框架设计指南：可重用 .NET 库的约定、习惯用法和模式 ，之后也发布在 MSDN 上。 更好的消息是有 2 个工具实现了这个标准：

• StyleCop - 检查源代码文件
• 代码分析（以前称为 FxCop，现在集成在 VS 中）- 检查已编译的代码

以下是配置这些工具使其在解决方案生成时运行的详细步骤。

解决方案 StyleCop 配置

为了为项目定义 StyleCop，首先解决方案必须具有 StyleCop 规则设置和 StyleCop 可执行文件。

 

以下是我在 StyleCop 的默认规则集中禁用的规则

• 文档规则
  • SA 1600 – 元素必须有文档
  • SA 1633 – 文件必须有标头
  • SA 1634 – 文件标头必须显示版权
  • SA 1635 – 文件标头必须有版权文本
  • SA 1637 – 文件标头必须包含文件名
  • SA 1638 – 文件标头文件名文档必须与文件名匹配
  • SA 1640 – 文件标头必须有有效的公司文本
• 排序规则
  • SA 1200 - Using 指令必须放置在命名空间中
• 空格规则
  • SA 1027 – 不得使用制表符

解决方案代码分析配置

将代码分析规则集和字典添加到解决方案根目录。

我使用的推荐规则集是“Microsoft All Rules”，没有规则

• CA2210 程序集应具有有效的强名称 (设计)
• CA1062：验证公共方法的参数 (设计)
• CA1303：不要将文本作为本地化参数传递（全球化）
• CA2233：操作不应溢出 (用法)
• CA2204：文本应正确拼写（命名）– 有用，但它 无法正常工作。

查看更多关于 代码分析字典的信息。

项目手动配置

要将代码分析字典和 StyleCop 集成到构建中，卸载并编辑项目，然后添加以下标记。 请注意，路径可能因解决方案配置而异。

<ItemGroup>
    <CodeAnalysisDictionary Include="$(SolutionDir)\CodeAnalysisDictionary.xml" />
</ItemGroup>

<Import Project="$(SolutionDir)\ExternalDlls\StyleCop 4.7\StyleCop.targets" />

 

项目构建配置

在项目属性上将编译器警告级别配置为 4（最严格）。

检查 XML 文档文件（除非它是测试项目，并且不需要文档，因为测试是自文档化的）。

项目代码分析配置

配置项目调试配置以使用解决方案根目录中的代码分析规则。 对发布配置执行相同的操作。 唯一的区别是在调试模式下不应运行代码分析，因为它会减慢构建速度。 我们保持 CA 在发布版本中运行，以从持续集成获取错误报告，并允许通过将解决方案模式从调试更改为发布来轻松打开 CA。

 

 

JS 怎么样

我仍然没有弄清楚这一点，但我希望 WebEssentials 能够添加在构建时轻松运行 JSHint 的可能性，并配置不扫描哪些 .js 文件。