C# Lambda表示法与逻辑比较

lambda符号

x => x.MyProperty

很容易被一些人混淆为大于或等于。即

if (x => y) ...

问题是：编译器是否曾经混淆这些？也就是说，是否应通过一项公约，规定大于或等于始终编码为：

if (x >= y) ...

我想编译器可以根据上下文来区分这两种语言，但是“最佳实践”是什么呢

关于这一点的问题

从某种程度上可以看出，很容易出错

编辑：

鉴于这一次酝酿的小风暴，以下可能会澄清

我问这个问题是因为我回答了一个问题，那家伙把lambda符号打错了。我指出了他的打字错误，他接受了我的回答。上面的问题有一个链接

这个问题使我恼火。我一直使用>=没有很好的理由，但我确信我看到过使用其他符号的代码。有时候，你会假设自己不想提问。它可能来自于我的VBA时代，也可能不是，但我确信我已经看到过编译、运行并使用=>进行大于比较的代码。就这样吧。我很抱歉没有“启动VS”，但我整天都在没有安装VS的办公室里与Sitefinity一起工作。没有借口，我同意你

但请注意，C#中的lambda表达式仅与….一样古老。网络2？还是.NET3.5。考虑到我从1.0版开始就使用C#on和off，这个问题是错误的，但并没有那么荒谬

我还认为SO的严格规则非常好，因为它们可以产生原始的问答。但是有不同的方法来应用这些规则。从9月中旬开始，我就一直在认真地使用它，所以我认为最好是对糟糕的问题发出警告，而不是一有机会就动膝盖。这就是它所鼓励的：留下评论，而不是仅仅触发快乐的扣分。你让提问者有机会意识到他们的错误，并从系统中删除一个毫无意义的问题。因为一旦答案和选票蜂拥而至，提问者就无法删除该问题

rant的结尾。

=>是lambda运算符

格栅或同等物>=

我不认为它会被混淆，因为如果（x=>y）是无效代码，它们是不可互换的

比较运算符（

x>=y

和

x
编译器是否曾经混淆过这些

不。在C#（我在看标签）中，
=
始终是比较；
=>
始终是lambda表达式。有

我想编译器可以分辨
二者之间基于上下文

编译器不需要上下文来区分这两者；请参见上文

也就是说，应该通过一项公约吗
大于或等于的
始终编码为：

if (x >= y) ...

如果（x>=y）

是的，因为这是编译器接受它的唯一方式。：-）

关于人为错误，我认为以下助记符有帮助：


我们几乎总是说“大于或等于”，而不是“等于或大于”
数学符号将“大于”或“小于”置于表示“或等于”的线上方。这可以很自然地转换为从左到右的顺序
C#中lambda表达式使用的符号看起来像一个箭头，指向返回值的表达式。它可以被认为是“收益率”
一个有趣的问题，尽管在实践中我从未见过有人试图使用=>作为比较运算符。此外，根据惯例，我所拥有的每本关于编程的书都将逻辑大于比较运算符表示为“>=”@LarsH：因为这个问题毫无意义无法用于相等比较，它不会编译。此外，认为编译器混淆了两者，在我看来有点荒谬。@BFree：这个问题是完全有道理的，因为OP错误地认为=>和>=都可以用于比较。编译器需要上下文来区分两者的建议也是如此。在我看来，揭露一个重大的错误假设并纠正它几乎和问一个问题（没有错误的假设）并得到回答一样有用。惩罚提出诚实、明确问题的人毫无意义。“你不知道你不知道的东西”-直到你问。@LarsH：在问这样的问题之前，你可以做的就是启动Visual Studio，并进行测试，以确保你所说的事实是准确的。@Brian，@LarsH，@BFree:LarsH是正确的，这个问题一点也不荒谬。有些流行语言中>=和=>具有相同的语义。VBScript立即浮现在脑海中。VB IDE将自动将=>更正为>=但是如果您重写自动更正并强制它使用=>编译，那么编译仍然会成功。这是非常有效的语法。错误发生在语义分析过程中，而不是语法或词汇分析过程中，因为lambda表达式无法转换为bool。我怀疑我的误解来自于我从MS Access开始的事实。我用Access2007测试了这个假设，它没有抱怨，只是自动重新调整了角色。Ie，=>变成>=。对Access 200x不太确定。我敢肯定，我在工作应用程序中看到过VBA代码，它们没有区别。也许我应该启动VS来测试…埃里克：那么这个错误是在lambda表达式出现之前不久的几天里出现的吗？