经常在代码中使用标志是明智的吗？

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

这是非常主观的，并取决于其余的代码。你称之为“旗帜”的地方。

Answer 3

建议如果condition1是相当复杂的事情 - 如if (A && (B || C) && !D)或包含大量开销（if (somethingTimeConsumingThatWontChange())），那么存储结果而不是复制粘贴代码是有意义的。

如果condition1只是一个简单的比较然后不，我不会使用一个标志。

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(); 
} 

如果您使用的是强类型语言，多态性是你的朋友。我认为该技术refered为态分派

Answer 5

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

Answer 6

这是问题是有点通用。答案取决于你想要做什么以及你希望它做什么语言。假设面向对象的上下文比可能有更好的方法。

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

Answer 7

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

var $isNewRecord; 
var $hasUpdated; 

if ($isNewRecord) 
{ 
} 

if ($hasUpdated) 
{ 
} 

Answer 8

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

例如，考虑这个：

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) 

---

如果（VAR1 ==真）

再次。糟糕的编码风格。它是：

if (var1) 

Answer 9

铭记的代码可以更可读地写成

var1 = condition1 

，这个任务有一些有用的特性，如果用得好。一个用例的命名是一个复杂的计算而不会破坏它变成一个功能：

user_is_on_fire = condition_that_holds_when_user_is_on_fire 

，允许一个解释什么人使用的条件是指，这往往是从裸露条件下并不明显。

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

一些注意事项：命名错误的标志会降低代码的可读性。所以将标志放置在远离使用地点的地方。另外，人们想要使用标志的事实是一种代码异味，暗示应该考虑将条件分解为函数。

D'A

Answer 10

当您使用预OO语言工作时调用它的标志。它们对参数化一段代码的行为很有用。

但是很快你会发现代码难以遵循。例如，当你通过例如抽象的方式抽象出差异时，阅读/更改/维护会更容易。提供对可变功能的参考。

在功能是一流citisens（如Javascript，Haskell，Lisp，...）的语言中，这是一件轻而易举的事情。

在OO语言中，您可以实现一些设计模式，如Abstract Factory，Strategy/Policy ...

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

Answer 11

标志是非常有用的 - 但给他们明智的名字，例如使用“是”或类似的名字。

例如，比较：

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

有：

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

Answer 12

什么我不喜欢有关标志，是当他们被称为标志，没有任何评论。

e.g

void foo(...){ 

    bool flag; 

    //begin some weird looking code 

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

他们试图对代码redeability。而那位在原程序员离开后几个月/几个月必须阅读的可怜人，要想明白它最初的目的是什么，将会有些困难。

但是，如果标志变量具有代表性名称，那么我认为他们没问题，只要明智地使用（请参阅其他响应）。

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(); 
} 
... 

而且，从以下马丁·罗伯特（清洁守则）提醒，可重构逻辑成更有意义的方法：

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

所以，我已经看到了很多很多的代码，其中像上面简单的规则可以遵循，但人们不断加入无故并发症和标志！现在有合法的情况可能需要标志，但在大多数情况下，它们是程序员从过去继承的一种风格。