哪个更易于维护-通过if / else或布尔表达式进行布尔赋值?


11

哪个将更易于维护?

if (a == b) c = true; else c = false;

要么

 c = (a == b);

我尝试在“代码完成”中查找,但是找不到答案。

我认为第一个更具可读性(您可以从字面上大声读出来),我也认为这使其更易于维护。第二个当然更有意义并减少了代码,但是我不确定它对于C#开发人员是否可维护(我希望在Python中会更多地看到这种用法)。


3
两者不相等。您首先需要一个else c = false||=第二个要进行分配。

17
我认为您必须对第一种表单进行两次编辑的事实回答了您的问题!
詹姆斯

7
我同意@James。第二种形式虽然不那么冗长,但很容易理解,在含义上也没有歧义。没有技巧或捷径,只是因为概念很简单所以很短。您为第一个代码编写了一个错误,并且不得不对其进行修复以进行修复,并且它仍然不够完美(括号的用法不一致),这一事实证明了这并不像您想象的那么简单。
埃里克·金

5
哇,C#开发人员真的认为第一种形式可以接受吗?这严重降低了我对他们的信任。以我的经验,第一种形式的使用在很大程度上暗示了对布尔表达式的完全误解。
Andres F.

2
为了使事情有趣,这里还有另一个选择:c = a==b ? true : false;
FrustratedWithFormsDesigner 2012年

Answers:


14

第二种选择更好。

有绝对的理由要警惕聪明的编程快捷方式,因为它们会使代码的意图模糊不清,从而损害了可维护性。所以,我不怪你问这个问题。

但是,我不认为c = (a == b);这是一个巧妙的窍门。这是一个简单概念的直接表示。尽可能直接。

一个适当的“维护”您的第一个例子中的格式(不缺少括号和一个线结构,这是我做的认为一个聪明的快捷方式)会产生这样的代码:

if (a == b)
{
    c = true; 
}
else 
{
    c = false;
}

以我的经验,以这种冗长且易于出错的方式编写简单的布尔逻辑是“无用”代码的标志。这会让我想知道在此代码库中如何处理更复杂的逻辑。


15

首先,认识到您的两种形式不相等。

if (a == b) c = true;

c如果a等于b,则将其设置为true;如果不等于,则其值将保持不变。

c = (a == b);

c如果a等于b,则将设置为true;否则,将设置为false。

如果要以第二种形式的等效形式,以第一种形式的样式,则需要这样写:

if (a == b) {
  c = true;
} else c = false;

现在很明显,如果更改了某些内容,则两者中的哪一个更易读,更易于维护并且不太可能引入错误。坚持第二种形式。


完全正确-我已经更新了我的问题。
Bret Walker

我认为第二种形式过于冗长和复杂-如果您想要这种效果,请使用布尔分配。
恢复莫妮卡-M.Schröder'12

11

我不同意您的第一种形式更具可读性-在一行中同时包含两个语句当然不是惯用的C#,并且不建议您if不使用花括号就使用一个语句。

其次,我看不到第二种形式的可维护性如何-没有什么可维护的。这是关于a和之间关系的简单说明,b不能再简单地表达出来了。

选择第二种格式的另一个原因是,您可以c在一个语句中声明并分配它,即

bool c = (a == b);

修改变量很容易导致错误,因此我避免了。使用if语句要求先在条件之前声明变量,然后再进行修改。


我在一行中以伪代码读取了这两个语句
Jimmy Hoffa

1
为“ Another reason to prefer the second form is that you can declare c and assign it in a single statement” +1
Andres F.

0

“更易于维护”可能是非常主观的。

我通常更喜欢可读性和意图,而不是减少代码。我认为您可以使用简化形式保存8个键入的字符。

在我看来,将语言和文化围绕语言是“可读性”的特征。

有时可能会导致性能下降,从而减少代码以优化最终的字节码,但是在进行某些性能分析后,应谨慎进行。


主观:Duh。减少代码:也可以(如果没有过分的话)提高清晰度并更好地传达意图。性能:一点也不关心(优化有时是至关重要的,但这并不是优化的内容,因为它实际上并不重要-即使编写内核或驱动程序也可能无关紧要)。

4
第一种形式至少有一个需要纠正的错误,隐藏在其详细信息中。第二种形式很简单而且很关键,并且没有错误。我休息一下 无论如何,主要目的不是减少输入字符!这个问题根本不是关于性能的,在这种情况下这是无关紧要的。
Andres F.

@delnan,我的意思是,杜。别人的代码减少就是别人的澄清。我没有将优化作为主要关注点……我以它为例。您添加巧妙技巧或超出规范的原因应通过您/文化/企业认为可读的内容来平衡。
约翰尼2012年

1
编写干净的布尔表达式不是一个聪明的把戏!
Andres F.

我想,如果您实际上解决了问题的实质,而不是惯于用简单的类比来支持一个基本概念,那么我会在您的评论上加分。
约翰尼2012年

0

第二。它具有较少的重复(干)和容易理解到底是怎么回事,该c持有至与否值ab相等。

恕我直言,甚至更好

c = a == b

就像我写的那样

  • 1 + 2 + 3 代替 ((1 + 2) + 3)
  • 5 + 3 * 7 代替 (5 + (3 * 7))

显然并且不必要的代码不是一种美德。杂乱无章。


-4

不赞成投票的人,请详细说明我修改后的答案出了什么问题。

是的,c = (a == b);可能很难阅读(更糟糕的是,StyleCop抱怨不必要的括号),但是我仍然喜欢的简单性a == b。因此,当ab相同时,这是我喜欢使用的内容:

private static bool NoPeriod
{
    get
    {
        return this.MyWaveLength == this.HerWaveLength;
    }
}

然后,您可以执行以下操作this.c = this.NoPeriod

this.c = this.MyWavelength == this.HerWaveLength;

1
那是你的意思return this.MyWaveLength = this.HerWaveLength;还是return this.MyWaveLength == this.HerWaveLength;相反?
Jesse C. Slicer 2012年

5
什么!?c = (a == b);不是容易出错的。原始问题的第一种形式是更容易出错,如OP本身必须编辑其问题以修复错误所证明的那样!
安德烈斯·F

我猜您建议的解决方案有一个错误= vs. ==
Ondra 2012年

@OndraMorský,谢谢……编译器会为我抓到这个。
2012年

6
我对StyleCop不熟悉,但是如果它告诉您不必要的括号不好,则应将其关闭。不必要的括号对于编译器来说不是必需的,但是对于人眼来说,它们可能是非常非常好的。如果您写了c = a == b; 编译器可以很好地解决这个问题,但是对人类来说却很难。
Michael Shaw
By using our site, you acknowledge that you have read and understand our Cookie Policy and Privacy Policy.
Licensed under cc by-sa 3.0 with attribution required.