为什么C#不接受布尔运算符作为单词(“and”、“or”、“not”…)和当前运算符?

有几个很好的理由:

• 有一些细微之处,这些词表达得不太好。例如,短路和运算符与不短路的运算符(&vs&)。VB最近(ish)引入了一个名为AndAlso的短路和运算符。那对我来说毫无意义。它似乎从一开始就让人困惑。

• 少打字。布尔逻辑在任何地方都被使用,每个表达式上保存的几个击键加起来会非常多——或者至少,我发现必须键入更多的内容是相当烦人的。

• 因为它是C,java,ObjuleC和C++程序员所用的。人们使用这种语法已经有40年了(?)-几年了。它给人们似乎喜欢的语言增添了一种连贯性。

• 添加更多表示相同事物的运算符对于语言的操作是不必要的,并且可能会造成混淆。

如果您希望您的代码更“可读”,那么也许VB是一个更好的选择。有这样的说法是完全正确的

If value Is Not Null Then
   'do something
End If

我个人发现的c#语法!和&&和| |非常可读,因为它们在许多语言中是一致的,而且也倾向于遵循数学中使用的惯例,这些运算通常起源于这些惯例。

这也意味着没有含糊不清的含义,因为它是一个符号。

一句话,问题在于复杂性。从可用性的角度来看,你不想把开发人员和做同一件事的多种方法混为一谈。从编译器的角度来看,标记越多,性能就越差。很明显,多一个代币不会有什么不同,但想想其他人可能要求的所有其他裁员。最好强迫每个人都以同样的方式做事。至少这样,我们一定会继续回到堆栈溢出!

我有一个有趣的想法。通常你想使用语言的属性。如果有一个正规形式的逻辑表达式,其中逻辑运算的Polish树中的主运算符是AND(&),第一个操作数是false,则该语言不会计算其他操作数的值。类似地,如果逻辑运算的Polish树中的主运算符是OR(| |),并且第一个运算符为true,则不会计算其他操作数。我们来看几个例子

//...
// Position is a class
private bool checkMate(ref int numberOfPlies, ref ChessPosition position, int maxNumberOfPlies, List<Move> moves)
{
    if (numberOfPlies > maxNumberOfPlies)
        return false;
    position.makeMove(moves[numberOfPlies]);
    if (!(position.getSuccessOfLastMove())))
        return false;
    numberOfPlies++;
    return ((
            ((isCheckMate()) ||
            ((checkMate(ref numberOfPlies, ref position, maxNumberOfPlies, moves)))
           ));
}
//...

上述方法检查一个变量是否从给定的象棋位置导致将死,并且将死是以一定的层数给出的。Position是一个类,它的makeMove()方法在给定的位置进行移动,如果最后一次移动有效,它的getSuccessOfLastMove()为true,如果最后一次移动无效,它的getSuccessOfLastMove()为false。搬家是另一门课。Ply是国际象棋中的一个半步(move=白棋和黑棋,Ply=白棋或黑棋)。isCheckMate检查给定位置是否为将死。

但是,这里我们要计算所有操作数:

//... 黄花 返回(((花色== 花。黄色)或者 (花色== 花。淡黄色))以及 (花色变黄())); //...

上面的代码不是有效的C#代码,但让我们看看为什么需要C#中的OR。 在上面的例子中,我们想运行setColorToYellowIfTheCollorIsYellowish(),即使我们在计算函数之前知道整个计算的结果,但是代码不起作用,因为我们没有计算所有操作数的OR操作,即使我们知道结果。如果这是可能的,我们就不能用另一种方式编写函数。

//...
bool isThisFlowerYellowOrYellowish(Flower flower)
{
    if (flower.FlowerColor == flower.yellowish)
        return flower.setColorToYellowIfTheColorIsYellowish();
    return (flower.flowerColor == flower.yellow);
}

//...

与我认为的第二个例子相比,这是令人厌恶的。如果我们有一个“或”和一个“和”运算符,它没有经过优化,不管怎样都会计算所有的操作数,那么语言会更丰富,有一个特性,但是,没有这些运算符我们可以生存,因为我们在需要时有替代的解决方案,这是一个非常罕见的情况。

在我看来我们不应该改变主意!、| |、&、&和|运算符,因为所有的程序员都习惯了它们。如果在C#中更改它们,则该语言将不具有向后兼容性。