C#短空检查语法

本文关键字：语法 检查 | 更新日期: 2023-09-27 18:25:40

我最近在两个Objective C中都进行了大量编码，同时还参与了几个C#项目。在这个过程中，我发现我错过了两个方向的东西。

特别是，当我在C#中编码时，我发现我错过了Objective C.的短空检查语法

为什么你认为在C#中，你不能用如下语法检查对象是否为null：

if (maybeNullObject)  // works in Objective C, but not C#   :(
{
   ...
}

我同意if (maybeNullObject != null)是一种更详细/更清晰的语法，但一直在代码中编写它不仅感觉很乏味，而且感觉过于冗长。此外，我相信if (maybeNullObject)语法通常被大多数开发人员所理解（Javascript、Obj C，我认为还有其他语法）。

我把这个问题当作一个问题来抛出，假设C#不允许if (maybeNullObject)语法可能有特定的原因。然而，我认为编译器可以很容易地将对象表达式（如if (maybeNullObject)）自动（或自动）转换为if (maybeNullObject != null)。

这个问题的重要参考是一个想法如何成为C#语言的特性？。

编辑

我建议的短空检查语法只适用于对象。短null检查将不适用于基元和bool?之类的类型。

C#短空检查语法

因为C#中的if语句是严格的。它们只接受布尔值，不接受其他值，并且没有后续级别的"真实性"（即0、null等。它们是自己的动物，不存在隐式转换）。

编译器可以"轻松地将"几乎任何表达式转换为布尔值，但这可能会导致微妙的问题（相信我…），并且有意识地决定不允许这些隐式转换。

IMO这是一个不错的选择。您本质上是在要求一次性的隐式转换，编译器假设，如果表达式没有返回布尔结果，那么程序员一定想执行null检查。除了是一个非常狭窄的特征外，它纯粹是句法上的糖，几乎没有提供明显的好处。正如Eric Lippert所说，每一项功能都有成本。。。

你要求的功能会给语言增加不必要的复杂性（是的，它很复杂，因为类型可能定义了到布尔的隐式转换。如果是这样，则执行哪个检查？）只是为了让你不偶尔键入!= null。

编辑：

如何为@Sam定义到bool的隐式转换的示例（对于注释来说太长）。

class Foo
{
    public int SomeVar;
    public Foo( int i )
    {
        SomeVar = i;
    }
    public static implicit operator bool( Foo f )
    {
        return f.SomeVar != 0;
    }
}
static void Main()
{
    var f = new Foo(1);         
    if( f )
    {
        Console.Write( "It worked!" );
    }
}

一个潜在的冲突是与定义到bool的隐式转换的引用对象发生冲突。

编译器在if(myObject)检查null和检查true之间没有划分。

目的是不留下歧义。你可能会觉得这很乏味，但多年来，这种短兵相接的做法导致了许多错误。C#正确地有一个布尔值的类型，而不让0的值为false和任何其他值为true是出于良心的决定。

您可以针对System.Object编写一个扩展方法，也许名为IsNull（）？

当然，在为扩展类编写代码的基础上，还需要额外的8或9个字符。我认为大多数人都对显式null测试带来的清晰性感到满意。

相关文章：