Question

我在阅读别人的代码时遇到了很多旗帜，

if (condition1) 
    var1 = true
else
    var1 = false

然后，

if (var1 == true)
    // do something.

这样有很多旗帜。我很想知道，在代码中经常使用标志吗？

Answer 1

此：

if (condition1)
   var1= true;
else
   var1 = false;

是经典写得不好的代码相反，你应该写：

var1 = condition1;

是的，标志对于使代码更具可读性和可能性更快非常有用。

Answer 2

如果condition1非常复杂 - 例如if (A && (B || C) && !D)或包含大量开销（if (somethingTimeConsumingThatWontChange())），那么建议存储该结果而不是复制粘贴代码是明智的

如果condition1只是一个简单的比较，那么不，我不会使用旗帜。

Answer 3

这是非常主观的，取决于代码的其余部分。你所谓的“旗帜”就是他们的位置。

Answer 4

首先，此代码应如下所示：

var1 = condition1;

if( var1 )

// No need to compare *true* to *true* when you're looking for *true*

对于标志的数量，有更优雅的方法来分支您的代码。例如，使用javascript时你可以做这样的事情：

var methodName = someFunctionThatReturnsAString();

// assuming you name the method according to what's returned
myObject[ methodName ]();

而不是

if( someFunctionThatReturnsAString === 'myPreferedMethod' ){
    myObject.myPreferedMethod();
}else{
    myObject.theOtherMethod();
}

如果您使用的是强类型语言，那么多态性就是您的朋友。我认为该技术被称为多态分派

Answer 5

我记得重构书中的这个Replace Temp var with Query method。我认为这种重构会使代码更具可读性，但是，我同意它可能会影响性能，当查询方法很昂贵时...（但是，也许查询方法可以放在自己的类中，结果可以缓存进入那个班级。）

Answer 6

这个问题有点泛泛。答案取决于您想要做什么以及您希望它使用哪种语言。假设OO上下文比可能有更好的方法。

如果条件是某个对象状态的结果，那么“flag”应该可能是对象本身的属性。如果它是正在运行的应用程序的条件，并且您有很多这些东西，那么您可能应该考虑状态模式/状态机。

Answer 7

标志非常有用 - 但要给它们合理的名称，例如在他们的名字中使用“是”或类似的东西。

例如，比较：

if(Direction)    {/* do something */}
if(PowerSetting) {/* do something else */}

使用：

if(DirectionIsUp) {/* do something */}
if(PowerIsOn)     {/* do something else */}

Answer 8

如果它是可读的并且完成了工作，那么它没有任何问题。只需使用“has”和“is”前缀即可使其更具可读性：

var $isNewRecord;
var $hasUpdated;

if ($isNewRecord)
{
}

if ($hasUpdated)
{
}

Answer 9

这取决于条件和使用次数。无论如何，重构函数（如果条件计算缓慢，最好缓存结果）可能会给你更多可读代码。

例如考虑这个：

def checkCondition():
  import __builtin__ as cached
  try:
      return cached.conditionValue
  except NameError:
      cached.conditionValue = someSlowFunction()
      return cached.conditionValue

至于编码风格：

if (condition1)
   var1= true
else
   var1 = false

我讨厌那种代码。应该简单地说：

var1 = condition1

或者如果你想确保结果是布尔值：

var1 = bool(condition1)

if（var1 == true）

再次。编码风格不好。它是：

if (var1)

Answer 10

请记住，该代码可以更容易编写为

var1 = condition1

，如果使用得当，这个赋值有一些有用的属性。一个用例是命名一个复杂的计算而不将其分解为函数：

user_is_on_fire = condition_that_holds_when_user_is_on_fire

这允许人们解释使用条件的意思，这在裸露的情况下通常不明显。

如果评估条件昂贵（或有副作用），也可能需要在本地存储结果，而不是重新评估条件。

一些警告：错误命名的标志会使代码的可读性降低。所以将标志设置在远离它们使用的地方。此外，一个人想要使用标志的事实是一种代码气味，暗示人们应该考虑将条件分解为一个函数。

D'A

Answer 11

使用pre-OO语言工作时调用它。它们可用于参数化一段代码的行为。

但很快就会发现很难遵循的代码。当您通过例如抽象差异来阅读/更改/维护时，这将更容易提供可更改功能的参考。

在函数是一流的citisens（例如Javascript，Haskell，Lisp，...）的语言中，这是轻而易举的事。

在OO语言中，您可以实现一些设计模式，如抽象工厂，策略/策略，......

我个人认为太多的开关是代码味道。

Answer 12

我不喜欢旗帜，就是当它们被称为旗帜时，没有任何评论。

e.g

void foo(...){

     bool flag;

    //begin some weird looking code

    if (something)
       [...]
      flag = true; 
 }

他们试图反对代码可重复性。在最初的程序员离开后数月/年后必须阅读它的穷人，将会有一些困难时间试图了解它最初的目的是什么。

但是，如果flag变量具有代表性名称，那么我认为它们没问题，只要明智地使用（参见其他回复）。

Answer 13

是的，这只是愚蠢无意义的代码。

您可以将所有内容简化为：

if (condition1)
{
  // do something
}

Answer 14

这是我的看法。使用标志的代码：

...
if (dogIsBarking && smellsBad) {
  cleanupNeeded = true;
}
doOtherStuff();
... many lines later
if (cleanupNeeded) {
  startCleanup();
}
...

非常不洁净。程序员只是按照他的思想告诉他的任何顺序进行编码。他只是在一个随机的地方添加代码以提醒自己以后需要清理......为什么他不这样做：

...
doOtherStuff();
... many lines later
if (dogIsBarking && smellsBad) {
  startCleanup();
}
...

并且，根据Robert Martin（清洁代码）的建议，可以将逻辑重构为更有意义的方法：

...
doSomeStuff();
... many lines later
if (dogTookADump()) {
  startCleanup();
}
...
boolean dogTookADump() {
  return (dogIsBarking && smellsBad);
}

所以，我已经看到很多代码可以遵循上面的简单规则，但是人们无缘无故地添加并发症和标志！现在，存在可能需要标记的合法情况，但对于大多数情况，它们是程序员从过去继承的一种风格。

是否经常在代码中使用标志？

14 个答案: