在条件运算中使用 true 和 false 作为表达式答案

【问题标题】：Using true and false as the expressions in a conditional operation在条件运算中使用 true 和 false 作为表达式
【发布时间】：2011-03-10 19:52:22
【问题描述】：

我正在维护一些代码，并且发现了很多以下模式：

var isMale = (row["Gender"].ToString() == "M") ? true : false;

而不是这个：

var isMale = (row["Gender"].ToString() == "M");

有什么理由为什么有人会这样做吗？有没有人认为前者更具可读性或更清晰？是否存在某种旧的 C“陷阱”？

【问题讨论】：

是的，明确地写“true”和“false”让我更容易阅读，尤其是当你把它设为模糊类型（var）时。我花了几秒钟才理解第二个而不是第一个。 YMMV。
@DOK 有趣的评论。那么，如果明确声明了类型（bool），你认为第一个还是更可读？
我宁愿在这里看到bool 而不是var。
我认为像这样的代码提高可读性的唯一方法是如果读者没有清楚地理解 operator== 是一个 boolean 运算符，但使用三元运算符是完全多余。如果难以理解这段代码或者 'isMale' 将是一个布尔值（考虑到它的命名方式，这应该不是问题），那么像这样的注释：// bool 将是比冗余运算符更适合初学者，或者更好的是，使 isMale 成为实际的布尔值。
我只是不明白为什么除了学习者之外的任何人都会写第一个案例。键盘迷？也希望它是一个布尔而不是一个变量。如果是学习者代码，那没关系，但如果我雇佣了一个实习生来写代码，我会非常担心。

标签： c# coding-style readability conditional-operator

【解决方案1】：

一个正当的理由？没有。

它通常由不真正理解条件本身也是表达式的人产生，产生布尔结果。尤其是，人们学习的语言并非如此，例如 BASIC 的许多变体。

【讨论】：

了解我对开发者的了解（我同意，这是一个奇怪的短语），这听起来很可能是原因。

【解决方案2】：

我猜如果你是通过有效的角色获得报酬的。除此之外，我想不出任何理由。

【讨论】：

您找到了这样做的一个好理由！话虽如此，如果我按角色获得报酬，我会退出；）
如果我是按角色获得报酬，我会决定为我即将退休的买哪个岛。
@Matt - 除非你每个角色得到一个旧土耳其里拉的报酬……否则你永远无法退休。
@Reed：如果我按角色获得报酬，我会看看能否获得一份 COBOL 工作。然后，在编写了一些简单的程序后，我将改造浴室并重做屋顶。
当然可以，只需编写一个小实用程序，为每个源文件添加大约 30 兆的 cmets。

【解决方案3】：

如果您不能信任：(row["Gender"].ToString() == "M") 来正确地生成真或假，那么您可能也不能真正信任：(row["Gender"].ToString() == "M") ? true : false;。可以肯定的是，您无疑需要至少再重复几次：

(row["Gender"].ToString() == "M") ? true : false ? true : false ? true : false;

再一次，也许你也不能单独相信 == 和 ?: 的组合 -- 真的确定，你可能至少需要更多的冗余：

if ((row["Gender"].ToString() == "M") ? true : false ? true : false ? true : false == true)
    isMale = true == true;
else
    isMale = false != false;

嗯……也许我昨晚睡得太晚了……:-)

【讨论】：

出于某种原因，“假！=假”让我发笑
@Neil：我会在加号列中计算它...... :-)
+1。用递归例子指出逻辑谬误的伟大而幽默的方式来证明冗余（冗余[冗余]）。

【解决方案4】：

我认为这完全是多余的。

根据我的经验，当条件语句随着时间的推移而演变并最终以明确的真或假而不是子语句结束时，通常会发生这种情况。

【讨论】：

我想我明白你的意思了。我不确定我正在查看的代码是否属于这种情况，因为它非常一致。

【解决方案5】：

我猜有些人不喜欢将 true 或 false 以外的任何内容分配给布尔变量。不知道为什么会这样，但我观察了很多次。

所以，从这方面来看，它看起来像：

开启讽刺

bool isMale = (row["Gender"].ToString() == "M"); //BAAAAD

但是

bool isMale = (row["Gender"].ToString() == "M") ? true : false; //BETTER

和

bool isMale;
if (row["Gender"].ToString() == "M") 
    isMale = true;
else 
    isMale = false;   // BEST!

关闭讽刺

幸运的是，Resharper 简化了所有这些反模式。

【讨论】：

有时人们/团队甚至会在编码标准这样的条件下要求大括号，为此添加更多行。而且你提醒我，我需要购买自己的 ReSharper 许可证，因为我换了工作并且非常想念它......
我不介意再输入几个字符以获得更好的可读性。特别是如果他们要将其设为 var。虽然我更愿意将 isMale = true 与“if”放在同一行，但我已经看到编码标准不仅希望它在单独的行上，而且在大括号中，正如 David 所倡导的那样。
我很惊讶这么多人同意这一点。我可以比上一个更快地看到第一个示例中的意图。你们都是按角色收费的吗？ ;)
我不会对此投反对票，因为我不想要 n00b 军队的愤怒，但你以相反的顺序订购了东西（最好到最坏）。第一个对于理解 operator== 是布尔表达式的人来说是最清楚的！ “[...] 将除 true 或 false 之外的任何内容分配给布尔变量 [...]”该表达式 (x==y) 仅计算为 true/false!!! 编译器可以优化就是这样，但是您引用为“最佳”的最后一个解决方案不太可能被优化 [...]
如果您统一编写这样的代码，那么您将花费额外的精力来确保您将到处浪费时钟周期！如果您发现此代码更具可读性，是否听说过注释？无需为文档目的使用 if/else！

【解决方案6】：

if (somebool) return true;
else return false;

“模式”几乎在我工作过的任何地方都会被嘲笑。我认为没有理由这样做。

【讨论】：

【解决方案7】：

应用三元运算符 ?: 对于只能计算为真/假的表达式 (x==y) 完全是多余的（它完全是多余的 [它是多余的]）。

对于不太懂英语的人来说，上面的句子可能更容易阅读，因为他们会知道首先在字典中查找什么，并且如果说出来，由于重复。然而，对于以英语为母语的人来说，这句话很尴尬，而且是多余的。

在您的示例中，运算符被用于文档目的，或者，无意冒犯，我怀疑对运算符和表达式的工作方式理解不足。

无论是缺乏理解还是一些奇怪的文档尝试，我们都可以在没有像这样的冗余运算符的情况下做到这一点：

var isMale = (row["Gender"].ToString() == "M"); // bool

或者...

var isMale = (row["Gender"].ToString() == "M"); // true/false

... 或者更好的是，为 'isMale' 明确指定适当的类型，而不是依赖隐式类型：

bool isMale = (row["Gender"].ToString() == "M");

我还看到人们以这种方式（或使用 if/else）来悲观他们的代码：

bool something = some_int ? true: false;

没有必要这样做，虽然编译器可能会对此进行优化，但在像这样简单的事情上依赖分支机制本质上效率较低：

bool something = some_int != 0;

...具有相同的效果，但没有使用条件分支的迂回过程。

这种代码实在是太尴尬了。就像看到：

switch (x)
{
    case 1: 
        y = 1;
        break;
    case 2:
        y = 2;
        break;
    case 3:
        y = 3;
        break;
    // etc. for all possible values of x
}

上面的代码肯定会被大多数人认为是 uber-n00b 代码，但它在逻辑上并不比 x == y ? true: false 或 x ? true: false 少（与 x != 0 相反）。

【讨论】：

【解决方案8】：

绝对是多余的。可能是原始开发人员保留的另一种编程语言/环境的剩余实践。我还可能会看到开发人员认为第一行更具可读性，因为他/她在浏览代码时可以快速看到它正在设置布尔值。

【讨论】：

【解决方案9】：

第二种方式肯定是最有意义的，我认为它更容易阅读。

第二种方法更聪明一点。如果我在星期五下午大量编写代码并且我的大脑已经在周末消失了，我不会像你发现的那样做这样的事情:-)

【讨论】：