应该在左侧或右侧检查null

时间:2015-12-11 17:36:04

标签: c# null coding-style

在审核一些代码时,我看到了:

mongodb

我也看到了:

if (null == condition) { ... }

我似乎记得左侧有if (condition == null) { ... } 是有利的,但我无法记住它,并且认为它是一个较旧的运行时项目已经使用较新的.NET运行时进行了优化。我倾向于使用后一种无效检查,所以前一种检查引起了我的注意。

这是一个风格问题,还是让null位于评估的左侧或右侧?

3 个答案:

答案 0 :(得分:7)

C风格语言的经典原因是防止错误输入平等==作为赋值=。你不能分配一个常量 - 即以下是非法的,因此编译器将捕获该错误:

if (false = condition) { ... }

虽然这是完全合法的(但可能不是作者的意图:

if (condition = false) { ... }

注意:这个问题在C#中有限(与vanilla C相比)因为if语句需要bool(如下面的注释中所述),所以这实际上导致问题的唯一情况是你的类型是bool

答案 1 :(得分:4)

它可以在三种情况下产生影响。

其中一个是condition = null的拼写错误在if中有效。这在C风格的语言中更为常见,它允许null中的if(值为false),这是大多数,但不是C#。

可以在C#中创建具有此效果的类型:

public class Test
{
  public static bool operator true(Test x)
  {
    return true;
  }
  public static bool operator false(Test x)
  {
    return false;
  }
}
void Main()
{
  Test test = new test();
  if (test = null)
  {
    Console.WriteLine("!");
  }
}

重载这些运算符的次数并不是很多,特别是因为.Net 2.0引入了泛型(它对于像SqlBoolean这样的类型更有价值,它使值能够表示true,{{我们现在使用false)的方式是1}}或null

因此,这种情况在C#中非常有限。

另一个是类似的,如果有隐式转换为bool?或类型反过来实现booltrue运算符:

false

由于某些原因,隐式运算符值得避免,但这比第一个例子稍微有点可能,但仍然不太常见。

另一个是如果void Main() { Test test = new Test(); if (test = null) { Console.WriteLine("!"); } } public class Test { public static implicit operator bool(Test x) { return true; } } 以非对称方式过载:

==

但是,由于非对称public class Test { public static bool operator == (Test x, Test y) { return ReferenceEquals(x, null); } public static bool operator !=(Test x, Test y) { return !(x == y); } } void Main() { Test test = new Test(); if (test == null) { Console.WriteLine("This won't print."); } if (null == test) { Console.WriteLine("This will print."); } } 始终是一个错误,因此这取决于运算符中的错误以产生任何影响。这可能比第一种情况稍微更频繁地发生,但是当它发生时它应该被修复,所以它更不是真正的关注。

因此虽然它可以在C#中产生影响,但这种情况很少见,并且主要是基于其他人做过他们不应该做的事情。

因此,它主要是风格问题。首先放置==的人倾向于从语言中选择它,因为它会产生更大的差异。

答案 2 :(得分:1)

无论(null == condition)如何编译,使用像null这样的示例性值作为第一个(左)操作数都是违反直觉的。相反,第一个操作数应该建议您要评估的内容。