validation - Microsoft 代码契约框架有多成熟？

Question

Microsoft 最近发布了其 Code Contracts 的版本具有商业许可证的 DevLabs 框架。我们有兴趣在我们的项目中使用它们(主要是 C#，一些 C++/CLI)来逐渐替换所有自定义验证代码，但我很想在我们 promise 之前了解其他人使用它的经验，具体来说:

• 您认为该框架对于大型且复杂的商业项目来说是否足够成熟？

• 您在使用过程中遇到了哪些问题？

• 您从中得到了什么好处？

• 目前的痛苦是否超过其值(value)？

我意识到这是一个有点主观的问题，因为它需要意见，但考虑到这个框架是 .NET 4.0 的一个非常重要的部分，并且将(可能)改变我们编写验证代码的方式，我希望这个问题将保留收集有关该主题的经验的机会，以帮助我对一个具体的、可回答的问题做出决定:

Should we be starting to use it next month?

请注意，我们不提供代码 API，仅提供 Web 服务，因此对于大多数代码破坏而言，抛出异常类型的兼容性不是问题。然而，由于我希望不仅仅是我，更多的人会从这篇文章及其答案中受益，因此非常欢迎有关该领域的任何详细信息。

Answer 1

对此问题的最后一次成熟回应是在 2009 年，当时 .NET 4 已经发布。我认为我们应该进行更新:

代码契约对于您的调试版本来说可能已经足够成熟。

我意识到这在某种程度上是从“无害”到“基本无害”的升级。

Code Contracts home page链接到 PDF 格式的相当详尽的文档。该文档在第 5 节中概述了使用指南。总而言之，您可以选择自己的勇气，让合约工具在您的发布版本中重写 IL。

我们正在使用“不要重写我的发布 IL”模式。

到目前为止，我最喜欢这个意想不到的好处:代码更少，因此需要测试的代码也更少。你所有的保护条款都会消失。

if(arg != null) { 
    throw new ArgumentNullException("arg"); 
}
// Blank line here insisted upon by StyleCop

变成:

Contract.Requires(arg != null);

你的函数更短。 您的意图更加清晰。而且，您不再需要编写名为 ArgumentShouldNotBeNull 的测试来达到 100% 的覆盖率。

到目前为止，我遇到了两个问题:

• 我进行了一个单元测试，该测试依赖于契约(Contract)失败才能成功。您可能会认为该测试的存在是一个错误，但我想以测试的形式记录这一特定的禁令。由于我没有安装工具，因此在我的构建服务器上测试失败。解决方案:安装工具。

• 我们正在使用两个重写 IL 的工具:Code Contracts和 PostSharp 。他们相处得不太好。 PostSharp 的 2.0.8.1283 修复了该问题。不过，我会谨慎评估任意两个 IL 重写工具如何相处。

到目前为止，好处大于危害。

解决其他答案中提出的过时问题:

• Code Contracts 的文档相当详尽，但遗憾的是 PDF 版本。
• 至少有一个Code Contract forum由微软托管。
• 如果您拥有任何 VS2010 许可证，则代码契约(Contract)标准版是免费的。
• .NET 4 已发布。我在实现通用集合接口(interface)时遇到了微软的契约(Contract)。