14

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

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

而不是这个：

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

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

4

9 回答 9

19

一个正当的理由？不。

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

于 2010-07-01T20:18:38.920 回答
16

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

于 2010-07-01T19:59:57.950 回答
10

如果你不能相信：(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;

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

于 2010-07-01T20:33:54.743 回答
4

我认为这完全是多余的。

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

于 2010-07-01T20:00:59.113 回答
4

我猜有些人不喜欢将其他任何东西分配给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 对所有这些反模式做了简短的工作。

于 2010-07-01T20:03:13.357 回答
3

这

if (somebool) return true;
else return false;

“模式”几乎在我工作过的所有地方都会被嘲笑。在我看来没有理由这样做。

于 2010-07-01T20:40:39.300 回答
2

应用三元运算符 ?: 对于只能计算为真/假 ( 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: falseor少x ? true: false（与 相对x != 0）。

于 2010-07-02T05:42:39.863 回答
1

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

于 2010-07-01T20:04:26.723 回答
1

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

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

于 2010-07-01T20:06:09.980 回答