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

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

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

  • 你从中得到了哪些好处?

  • 目前的痛苦是否超过其价值?

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

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

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

有帮助吗?

解决方案 2

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

当您在只有自己的代码和原始类型的完全隔离的环境中工作时,契约似乎很棒,但是一旦您开始使用 BCL 类(在 .NET 4.0 之前没有自己的契约),验证者就无法检查它们是否会违反任何要求/确保/不变量,因此您会收到很多有关可能不满足约束的警告。

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

所以我的感觉是,目前,因为在 3.5 中我们试图构建一个验证者无法充分理解的框架,所以可能值得等待 4.0。

其他提示

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

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

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

代码合同主页 链接到 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 的工具: 代码合约后锐利. 。他们相处得不太好。PostSharp 的 2.0.8.1283 修复了该问题。我会谨慎评估如何 任何 不过,两个 IL 重写工具相处得很好。

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

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

  • Code Contracts 的文档相当详尽,但遗憾的是 PDF 格式。
  • 至少有一个 代码合约论坛 由微软主办。
  • 如果您拥有任何 VS2010 许可证,则代码合同标准版是免费的。
  • .NET 4 已经发布。我在实现通用集合接口时遇到了微软的合同。

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

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

还不够成熟。

一旦微软将其与 VS 的经济版一起发布,它就会出现,但如果没有静态代码分析,它根本无法使用。

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

遗憾的是微软用他们的定价政策扼杀了这个令人惊叹的想法。我希望代码契约能够成为主流,但事实并非如此。

史诗般的失败。

许可以下: CC-BY-SA归因
不隶属于 StackOverflow
scroll top