43

微软最近在 DevLabs 上发布了他们的Code Contracts框架，并获得了商业许可。我们有兴趣在我们的项目中使用它们（主要是 C#，一些 C++/CLI）来逐步替换所有自定义验证代码，但我很想知道在我们承诺之前其他人使用它的经验，具体来说：

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

  • 你在使用过程中遇到了什么问题？

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

  • 目前是否比它的价值更痛苦？

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

我们应该下个月开始使用它吗？

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

4

4 回答 4

32

对此的最后一次成熟响应是在 2009 年，.NET 4 已经发布。我想我们该更新了：

对于您的 Debug 版本，代码契约可能已经足够成熟了。

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

Code Contracts 主页链接到 PDF 格式的完整文档。该文档在第 5 节中概述了使用指南。总而言之，您可以选择您对合约工具在您的发布版本中重写您的 IL 的感觉有多勇敢。

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

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

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

变成：

Contract.Requires(arg != null);

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

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

  • 我有一个依赖于合同失败的单元测试来成功。您可能会争辩说测试的存在是一个错误，但我想以测试的形式记录这一特殊的禁令。我的构建服务器上的测试失败了，因为我没有安装这些工具。解决方法：安装工具。

  • 我们使用了两种重写 IL 的工具：Code Contracts和PostSharp。他们相处得不太好。PostSharp 的 2.0.8.1283 解决了这个问题。不过，我会谨慎评估任何两种 IL 重写工具如何相处。

到目前为止，利大于弊。

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

  • Code Contracts 的文档非常详尽，但遗憾的是 PDF 格式。
  • 至少有一个由 Microsoft 托管的代码合同论坛。
  • 如果您有任何 VS2010 许可证，Code Contracts 标准版是免费的。
  • .NET 4 出来了。在实现通用集合接口时，我遇到了微软的合同。
于 2010-08-09T02:07:48.310 回答
9

在一个小型但中等复杂的独立项目中，我自己一直在玩代码协定，该项目需要从一些 BCL 类继承并使用其他类。

当您在仅使用自己的代码和原始类型的完全隔离的环境中工作时，合同看起来很棒，但是一旦您开始使用 BCL 类（在 .NET 4.0 之前没有自己的合同），验证者就无法检查它们是否会违反任何要求/确保/不变量，因此您会收到很多关于潜在未满足约束的警告。

另一方面，它确实发现了一些无效或可能不满足的约束，这些约束可能是真正的错误。但是很难找到这些，因为噪音太大，很难找出可以修复的那些。可以通过使用假设机制来抑制来自 BCL 类的警告，但这有点弄巧成拙，因为这些类将来会有合同，并且假设会降低它们的价值。

所以我的感觉是，就目前而言，因为在 3.5 中我们正在尝试构建一个验证者没有充分理解的框架，所以可能值得等待 4.0。

于 2009-03-26T20:11:10.953 回答
8

从这个线程来看，我会说它还不够成熟，无法用于企业级项目。我自己没有使用过它，但人们仍然会遇到错误，这些错误会使你的合同关键项目停止。这似乎是一个非常棒的框架，他们提供的示例视频令人兴奋，但我会等待：

  • 社区论坛的存在。您将希望能够与其他开发人员讨论您遇到的不可避免的问题，并且您想知道有相当强大的开发人员基础可以与他们讨论解决方案。
  • 成功的试点项目发布。一般来说，当微软研究院发布了他们认为已经成熟到可以用于商业项目的东西时，他们会与组织合作进行试点，然后将该项目开源作为概念证明和试运行的所有主要功能。这会给大多数常见的合同场景都涵盖并有效的信心。
  • 更完整的文档。简单明了，在某些时候，您会想要使用 Microsoft Code Contracts 无法完成的合同来做一些事情。您希望能够快速而清晰地推断出您的方案尚不受支持。当前的文档将让您不断猜测和尝试不同的事情，但在我看来，这将导致大量时间浪费。
于 2009-03-23T13:31:19.520 回答
2

还不够成熟。

一旦微软发布了价格实惠的 VS 版本，它就会立即发布，但如果没有静态代码分析，它就根本不可用。

拥有它的 VS 版本非常昂贵，只有少数人能够负担得起。

令人遗憾的是，微软用他们的定价政策扼杀了这个惊人的想法。我希望代码合同会成为主流，但他们不会。

史诗般的失败。

于 2010-06-27T13:58:29.157 回答