.NET 4.0 中的代码契约，对于不可为空引用类型的粉丝来说没有乐趣吗？

发布于 2024-08-07 05:33:37 字数 814 浏览 11 评论 0原文

我一直在 VS2008 上使用代码契约 (http://msdn.microsoft. com/en-us/devlabs/dd491992.aspx）。
它们确实很好，并且为方法内部的 if-then- throw 检查提供了可靠的替代方案。

尽管如此，我一直希望它们能够满足我对不可空引用类型的强烈需求。
唉，据我所知，情况似乎并非如此。
这就是我的理解：

这样的事情仍然会在运行时引起问题：
<代码> MyClass a = null;
a.ToString();
我仍然必须显式地编写检查，即使以更简洁和简化的方式。
除非您使用 VS Team System，否则您只能使用代码契约在运行时检查内容，在编译时没有任何好处。
这意味着当出现问题时你仍然必须处理事情。
与处理简单的异常没有太大区别。
即使使用 VSTS，静态分析也不像运行时那样好。
这是完全可以理解的，但这仍然是该功能适用于运行时使用的另一个标志。

如果我错了，请纠正我，但从我看来，代码契约不可能让我的生活更轻松，让我的程序更健壮，就像不可为空的引用类型那样。

不要误会我的意思，我并不不喜欢代码契约。
它们对整个框架来说是一个非常好的增强。
只是，如果这不能填补 C# 由于没有不可为空引用类型而留下的空白，那么目前恐怕什么都无法填补。
你怎么认为？

原文

分享到QQ

分享到微博

如果你对这篇内容有疑问，欢迎到本站社区发帖提问参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。

发布评论

需要登录才能够评论，你可以免费注册一个本站的账号。

做个少女永远怀春 2024-08-14 05:33:37

我认为你对此是正确的。编译时不可为空的引用检查是我在代码契约中等待的杀手级功能，但它实际上并不存在。

对于那些想知道这意味着什么的人，请考虑与值类型的类比。它们最初不可为空，但现在如果您在类型名称后面加上问号，则可以为空：

int? n;

为了保持一致性，如果引用类型也是如此，那将是理想的选择。但这会破坏所有现有的 C# 程序，因此不是一个选择。在研究语言 Spec# 中，他们使用感叹号后缀来表示不可为空：

string! s = "Hello";

与普通值类型一样，编译器静态检查 string! 变量在初始化之前是否未在任何代码路径上使用（我相信 Spec# 要求声明和初始化发生在相同的声明）。

它还禁止将 null 分配给该变量。

当然，它禁止将普通字符串分配给字符串！。那么如何弥合这两种类型之间的差距呢？通过编写检查：

string x = GetStringFromSomewhere();

if (x != null)
    s = x; // okay because compiler sees null check

可悲的事实是，如果程序正确，大多数程序中的大多数引用变量可能都是不可为空的。可空变量只占少数。然而它们是默认的。

20世纪60年代的另一个坏主意！

I think you're correct about this. Non-nullable reference checking at compile time was the killer feature I was waiting for in Code Contracts, and it isn't really there.

For those wondering what this means, consider an analogy with value types. They were not nullable originally, but now they are if you put a question mark after the type name:

int? n;

For consistency it would be ideal if the same was true of reference types. But that would break all existing C# programs and so isn't an option. In the research language Spec# they went with using an exclamation mark suffix to mean non-nullable:

string! s = "Hello";

As with ordinary value types, the compiler statically checks that a string! variable is not used on any code path before it has been initialised (I believe Spec# requires declaration and initialization to occur in the same statement).

It also bans the assignment of null to that variable.

And of course, it bans the assignment of an ordinary string to a string!. So how do bridge the gap between the two kinds of type? By writing a check:

string x = GetStringFromSomewhere();

if (x != null)
    s = x; // okay because compiler sees null check

The sad truth is that the majority of reference variables in most programs are likely to be non-nullable if the program is correct. Nullable variables are in the minority. And yet they are the default.

Another bad idea from the 1960s!

回复收藏 0 原文

酒与心事 2024-08-14 05:33:37

我不确定“不可为空引用类型”解决了什么问题。好的，所以这段代码抛出异常的可能性要小得多：-

a.ToString();

但是它是否可能是正确，因为它不可为空？ a 的初始值是多少？可能是该类型的一些默认“空”实例。在这种情况下，是不是更有可能使事情变得更难以调试，因为应该分配值的值却没有分配。仅具有一些默认行为而不是引发异常听起来不像我想要的。

I'm not sure what problem is solved by "non-nullable reference types". Ok so this code is much less likely to throw an exception:-

a.ToString();

However is it anymore likely to be correct because a it non-nullable? What would be the initial value of a? Probably some default "Empty" instance of the type. In that case isn't it more likely to make things more difficult to debug since values which should've been assigned a value haven't. Just having some default behaviour rather than causing an exception doesn't sound like something I'd want.

回复收藏 0 原文

绮筵 2024-08-14 05:33:37

我认为不可空引用类型的概念对于 ORM 生成的映射到数据库字段的属性非常有用。通常，您无法从属性（通常为字符串类型）判断基础字段是否可为空。对于可空值类型，您只需查找问号即可。

除了明显的 foo 之外，我不太担心静态检查！ = 空；失败了，但我认为智能感知作为可变意图的提示非常有用。

回复收藏 0 原文

可是我不能没有你 2024-08-14 05:33:37

编译时不可为空的引用检查是我在代码契约中等待的杀手级功能，但它实际上并不存在。

2017 年更新（8 年后），虽然不可空引用类型仍然不存在...可空引用类型可能。

Mads Torgersen（微软的 C# 语言 PM）确实提到了它在此推文中：

可空引用类型的原型终于来了！

“介绍 Nullable 对此进行了详细介绍C# 中的引用类型”，以及此视频中的“C# 7.1 提供的新功能”和7.2”。

如果我们只添加一种新的“安全”类型的引用类型，然后将现有的引用类型重新解释为另一种“安全”类型，则可以实现这一点。更具体地说，我们认为未注释的引用类型（例如字符串）的默认含义应该是不可为 null 的引用类型，原因如下：
我们认为更常见的是希望引用不为空。可空引用类型是比较罕见的类型（尽管我们没有足够的数据来告诉我们有多少），因此它们应该需要新的注释。
该语言已经有了可空值类型的概念和语法。两者之间的类比将使语言添加在概念上更容易，并且在语言上更简单。
除非您主动决定需要它们，否则您不应该给自己或您的消费者带来繁琐的空值负担，这似乎是正确的。空值，而不是不存在它们，应该是您明确必须选择的内容。
它看起来像这样：

class Person
{
    public string FirstName;   // Not null
    public string? MiddleName; // May be null
    public string LastName;    // Not null
}

该类现在能够表达每个人都有名字和姓氏的意图，但只有某些人有中间名。
因此，我们明白了将此语言功能称为“可空引用类型”的原因：这些是添加到语言中的类型。不可为空的那些已经存在，至少在语法上是这样。

这仍然是一个原型，最终可能会（或不会）出现在该语言中。
请参阅“C# 可空引用类型预览”了解更多信息。

Non-nullable reference checking at compile time was the killer feature I was waiting for in Code Contracts, and it isn't really there.

Update 2017 (8 years later), while Non-nullable reference type is still not there... nullable reference type might.

Mads Torgersen (C# Language PM at Microsoft) does mention it in this tweet:

The prototype of nullable reference types is finally here!

This is detailed in "Introducing Nullable Reference Types in C#", and in this video "new features available C# 7.1 and 7.2".

This can be achieved if instead we add only one new “safe” kind of reference type, and then reinterpret existing reference types as being the other “safe” kind. More specifically, we think that the default meaning of unannotated reference types such as string should be non-nullable reference types, for a couple of reasons:
We believe that it is more common to want a reference not to be null. Nullable reference types would be the rarer kind (though we don’t have good data to tell us by how much), so they are the ones that should require a new annotation.
The language already has a notion of – and a syntax for – nullable value types. The analogy between the two would make the language addition conceptually easier, and linguistically simpler.
It seems right that you shouldn’t burden yourself or your consumer with cumbersome null values unless you’ve actively decided that you want them. Nulls, not the absence of them, should be the thing that you explicitly have to opt in to.
Here’s what it looks like:

class Person
{
    public string FirstName;   // Not null
    public string? MiddleName; // May be null
    public string LastName;    // Not null
}

This class is now able to express the intent that everyone has a first and a last name, but only some people have a middle name.
Thus we get to the reason we call this language feature “nullable reference types”: Those are the ones that get added to the language. The nonnullable ones are already there, at least syntactically.

This is still a prototype, and might end up (or not) in the language.
See more at "The C# Nullable Reference Types Preview".

回复收藏 0 原文