使用true和false作为条件运算中的表达式

时间:2010-07-01 19:58:32

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

我正在维护一些代码,并且发现了以下模式:

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

而不是:

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

有什么理由为什么有人会这样做?有人认为前者更具可读性或更清晰吗?是否有某种旧的C“陷阱”,这是一个保留?

9 个答案:

答案 0 :(得分:19)

有正当理由吗?否。

它通常由那些不太了解条件本身也是表达式的人产生,产生布尔结果。特别是,人们在一种不是这种情况的语言上学习,例如BASIC的许多变体。

答案 1 :(得分:16)

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

答案 2 :(得分: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;
嗯......也许我昨晚熬夜了......: - )

答案 3 :(得分:4)

我认为这完全是多余的。

根据我的经验,这通常发生在条件语句随着时间的推移而演变并以明确的真或假而不是子语句结束时。

答案 4 :(得分:4)

我猜有些人不习惯将truefalse的其他内容分配给布尔变量。不知道为什么会这样,但我已经观察了很多次。

因此,从这个方面看起来像:

设置讽刺

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对所有这些反模式做了简短的工作。

答案 5 :(得分:3)

if (somebool) return true;
else return false;

“模式”在我曾经工作过的任何地方都被嘲笑。在我看来没理由这样做。

答案 6 :(得分:2)

应用三元运算符?:对于只能求值为真/假(x==y)的表达式才是完全冗余的(它只是完全冗余[它是多余的])。 < / p>

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

在您的示例中,要么运算符用于文档目的,要么没有任何意义,我怀疑对运算符和表达式的工作方式了解不足。

无论是缺乏理解还是对文档进行一些奇怪的尝试,我们都可以做到这一点,而不需要像这样冗余的运算符:

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: falsex ? true: false(与x != 0相反)。

答案 7 :(得分:1)

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

答案 8 :(得分:1)

第二种方式确保最有意义,我认为它更容易阅读。

第二种方式更聪明一点。我不会过去做一些类似于你在周五下午制作代码并且我的大脑已经在周末消失的事情: - )