經常在代碼中使用標誌是明智的嗎？

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

所以，我已經看到了很多很多的代碼，其中像上面簡單的規則可以遵循，但人們不斷加入無故併發症和標誌！現在有合法的情況可能需要標誌，但在大多數情況下，它們是程序員從過去繼承的一種風格。