C# 对于代码契约，我是否需要通过“确保”验证字段/属性初始化？

这个构造函数的要点是初始化一个字段，而契约仅仅捕获了这个意图。合同的复杂性与其适用的代码相同。对我来说，这感觉是多余的，好像我刚刚写了两次相同的代码（尽管从两个稍微不同的角度）

这种类型的“微契约”是必要的吗，还是代码契约从方法体中推断出来的呢？

我的观点是肯定的

---

如果您从实施中推断出合同，对实施的任何更改都可能会更改合同。这就像在1.0.0版中发布一个接口，并在1.0.1版中由于一个简单的错误修复而对其进行突破性的更改。当您向我保证

X=X

并且我是您代码的用户时，我希望您遵守您的承诺。请记住，契约程序集也可以与NuGet包中的库一起分发。

与您的示例有点类似，它看起来确实是多余的，因为它是一个非常简单的示例。但总的来说，我不认为一致性保证有什么害处。如果参数是

int capacity

，但您确保

Size==capacity

，该怎么办？这不太明显。你如何界定哪些是琐碎的/明显的/不需要的？读者会理解并同意吗？@hatchet:Re：“如果…？”那么就我而言，这将是一个不同的问题。我故意选择了那个特定的代码示例。“你在什么是琐碎的问题上划清界限…？”这是个好问题。我没有答案，因为代码契约划定了这条线，而不是我。因此，我的问题是，我看似微不足道的代码示例对于代码契约来说是否微不足道，我看到的问题是，经常跳过“琐碎”的情况会让代码用户深入代码内部，以确定哪些情况是您忽略了显而易见的情况的原因：1）您可以确保，但认为它琐碎；2）您不能确保，对于不明显的情况（对局外人而言）原因。@hatchet：你最后的评论值得回答！根据定义，合同与代码“冗余”。这是合同的前提，你可以对照代码检查。如果没有冗余，则无需检查。

using System.Diagnostics.Contracts;

class C
{
    public C(bool x)
    {
        Contract.Ensures(this.X == x);  // is this necessary?
        this.X = x;
    }

    public readonly bool X;  // could be a property instead,
}                            // I'm just trying to keep this example simple