Microsoft代码契约框架有多成熟?

对这一问题的最后一次成熟回应是在2009年,而.NET4已经过时。我想我们应该更新一下:

对于调试版本,代码契约可能已经足够成熟了。

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

这个 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);

你的意图更清楚。 而且,您不再需要编写一个名为ArgumentShouldbenull的测试来达到100%的覆盖率。

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

• 我有一个单元测试,它依赖于合同失败而成功。你可能会说测试的存在是一个错误,但我想以测试的形式记录这一特定的禁止。在我的生成服务器上测试失败,因为我没有安装工具。解决方案:安装工具。

• 我们使用两种工具重写IL: Code Contracts PostSharp . 他们相处得不太好。PostSharp的2.0.8.1283修复了该问题。我会谨慎地评估 不过,有两种IL重写工具很合得来。

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

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

• 至少有一个 Code Contract forum 由微软主持。
• 如果您有任何VS2010许可证,代码合同标准版是免费的。
• .NET4出局了。我在实现通用集合接口时遇到过微软的合同。

我自己在一个小型但中等复杂的独立项目中一直在处理代码契约,该项目需要继承一些BCL类并使用其他类。

当你在一个完全隔离的环境中工作,只有你自己的代码和基本类型,但一旦你开始使用BCL类(直到.NET4.0都没有自己的契约),契约的事情似乎很好验证器无法检查它们是否会违反任何requires/assures/invariants,因此您会收到很多关于潜在未满足约束的警告。

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

所以我的感觉是,现在,因为在3.5中,我们试图建立一个验证者没有充分理解的框架,它可能值得等待4.0。

根据 this thread 我想说,它还不够成熟,无法用于企业级项目。我自己并没有使用过它,但人们仍然会遇到一些bug,这些bug会使您的合同关键项目停止。这似乎是一个非常棒的框架,他们提供的示例视频非常令人兴奋,但我会等待:

• 社区论坛的存在。 您将希望能够与其他开发人员讨论您遇到的不可避免的问题,并且您希望知道有一个相当强大的开发人员基础,可以与他们讨论解决方案。
• 一个成功的试点项目发布。 一般来说,当微软研究院发布一些他们认为已经成熟到可以在商业项目中使用的东西时,他们将与一个组织合作进行试验,然后将该项目开源,作为概念证明和所有主要功能的试用。这将使人们对大多数常见合同场景都已涵盖并发挥作用充满信心。
• 更完整的文档。 简单明了,在某个时候,你会想要用契约做一些你还不能用微软代码契约做的事情。您希望能够快速、清晰地说明您的场景是正确的 但是,在我看来,当前的文档将让您不断猜测和尝试不同的事情,这将导致大量的时间浪费。

一旦微软发布了价格合理的VS版本,它就会出现,但是如果没有静态代码分析,它就根本不可用。

拥有它的VS版本非常昂贵,只有极少数人能买得起。

微软用他们的定价政策扼杀了这个惊人的想法,真是太遗憾了。我希望代码契约能成为主流,但它们不会。

史诗般的失败。