result = result ?? defaultValue;
相反,你可以写
result ?= defaultValue;
我并不是说这是一个好主意。
这个操作员有什么优势?
该操作员有什么缺点?
result = result ?? defaultValue;
相反,你可以写
result ?= defaultValue;
我并不是说这是一个好主意。
这个操作员有什么优势?
该操作员有什么缺点?
我不认为这是值得的。一般来说,你几乎总是会这样做:
result = someSourceValue ?? defaultValue;
你的第二种形式是一种特殊情况,很少使用。
从某些源读取值(如Web服务)时,null合并运算符最有用,并且您希望将缺失值强制为零或其他默认值。数据几乎总是来自某个地方,而去其他地方。
作为一个主持人,我真的很震惊,你很难回答这个问题。这显然只是一个投票问题,而不是建设性的;这个问题可能没有**答案**。它应该立即关闭。 – Yuck 2013-03-13 23:15:35
恐怖。 。 。 – 2013-03-13 23:16:54
可能不是。我只在C#中少量使用过空合并运算符,并且从不这样做。 C#做事的方式是编写显式的空检查,而不是无所畏惧的分配。 (没有冒犯性)
我确定很多人都想拥有这个操作符,但我认为它不会对语言有所帮助。
这只是我的看法。
当从某个源读取值(如Web服务)时,null合并运算符非常有用,并且您希望将缺失值强制为零或某些值。 – 2013-03-13 23:13:13
我同意。很多人不理解''''或'?:'那么为什么要添加'?='到混合中? – Yuck 2013-03-13 23:13:25
我看到的最大潜在优势是它能够提供其他复合运营商的相同优势,如+=
。考虑以下
Method().Field = Method().Field ?? someValue;
如果Method()
是昂贵的或有副作用,这些都会对这一说法进行了两次。为了防止这种情况发生,你就需要打破这种成2线
var temp = Method();
temp.Field = temp.Field ?? someValue;
这可能是一个有点乏味,如果你陷在这个位置。如果?=
与+=
具有相同的保证,即左侧的副作用只发生一次,则此额外线路不是必需的。
Method().Field += someValue; // Method() happens once
Method().Field ?= someValue; // Method() happens once
IMHO,其是由具有超过简单地??
?=
一个运营商提供的关键优势。这将是有价值的,但我不认为这将是值得加入到
此之前已经提出的语言,我根据服用这种想法到了极点我2011年4月愚人节的博客文章:
http://blogs.msdn.com/b/ericlippert/archive/2011/04/01/compound-assignment-part-two.aspx
与该帖子中提到的所有其他操作符不同,??=
实际上会有点用处。没有足够的理由来证明其“直接”成本 - 设计和实施和记录所有这些成本的时间和精力和金钱。它当然不能证明它的“机会”成本 - 花费在做一个相当愚蠢而不是特别有用的操作员上的时间,精力和金钱可能花费在直接解决开发人员实际遇到的实际问题的功能上。
它会解决哪些问题? – 2013-03-13 23:06:47
只有当你想混淆你的代码。 – 2013-03-13 23:08:47
确实+ =解决了一个问题? – Myster 2013-03-13 23:09:21