编程规范与构建指南

在编程的世界中，遵循一定的规范和构建指南是至关重要的。它们不仅能够提高代码的可读性和可维护性，还能帮助团队成员之间达成共识，减少不必要的沟通成本。正如Steve McConell所言，成功的编程关键在于避免任意的变异，以便大脑可以专注于真正需要变化的地方。

.NET编程规范

在.NET环境中，遵循微软内部使用的.NET编码标准是最佳选择。这一标准被详细记录在《Framework Design Guidelines: Conventions, Idioms, and Patterns for Reusable .NET Libraries》一书中，并且在MSDN上也有相应的文档。幸运的是，有两个工具可以帮助实现这一标准：

• StyleCop：检查源代码文件
• 代码分析（Code Analysis，之前称为FxCop，现在已集成在Visual Studio中）：检查编译后的代码

为了在项目中定义StyleCop，首先需要在解决方案中添加StyleCop规则设置和可执行文件。以下是从默认规则集中禁用的一些规则：

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

在解决方案根目录下添加代码分析规则集和字典。使用的推荐规则集是“Microsoft All Rules”，但不包括以下规则：

• CA2210 程序集应该有有效的强名称（设计）
• CA1062: 验证公共方法的参数（设计）
• CA1303: 不要将文字作为本地化参数传递（全球化）
• CA2233: 操作不应该溢出（使用）
• CA2204: 文字应该拼写正确（命名）—— 有用，但不正确

更多关于代码分析字典的信息，请参见。

为了在构建中集成代码分析字典和StyleCop，需要卸载并编辑项目，然后添加以下标签。注意，路径可能会根据解决方案配置有所不同。

在项目属性中将编译器警告级别设置为4（最严格）。检查XML文档文件（除非是测试项目，不需要文档，因为测试是自文档化的）。

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