冗餘代碼是否可以接受，如果它提高了可讀性？

我有以下代碼來檢查遊戲單位是玩家還是敵人。這是唯一的兩個類別。我可以刪除isEnemy方法並像對待（！isPlayer）一樣對敵人執行所有檢查，但是我個人認爲如果（isEnemy）使代碼的意圖更清晰。是否有任何確定的編碼風格對這種情況有什麼要說的？冗餘代碼是否可以接受，如果它提高了可讀性？

public boolean isPlayer(Unit unit) { 
    return unit == player; 
} 

public boolean isEnemy(Unit unit) { 
    for (Unit e : enemies) { 
     if (unit.equals(e)) 
      return true; 
    } 
    return false; 
}

來源

2012-12-25 talloaktrees

恕我直言，如果你編寫代碼的目的，任何你不需要在那裏添加混亂。你可以浪費更多的時間去試圖找出沒有明確目標的東西的目的。在你的例子中，不清楚如何用另一種方法替換一種方法。 –

我覺得有兩種方法是可以接受的。！如果isEnemy（）== isPlayer（）我會考慮實施isEnemy（）爲：

public boolean isEnemy(Unit unit) { 
    return !isPlayer(unit); 
}

這樣你獲得有兩個具體方法，但不一定是重複自己，如果你能調整isPlayer的可讀性（）並影響這兩種方法。

來源

2012-12-25 04:36:39 Joe

在我看來，這是絕對可以接受的。特別是在大項目中，可讀性非常重要。另外考慮到，如果將來添加第三個角色，那麼您將無法使用if（！isPlayer）。

來源

2012-12-25 03:57:32 TieDad

就我個人而言，我會執行isEnemy()作爲!isPlayer()，但有一個assert運行循環，以確保它確實是一個敵人。

來源

2012-12-25 04:00:04 steveha

對於你的情況，你只有兩種可能的狀態 - 他們要麼是敵人，要麼是玩家。如果他們是球員，他們不是敵人。最簡潔的表達方式是!isPlayer。

如果您有其他可能的狀態，那麼您可能想要查看其他狀態的某種枚舉。

作爲一般的經驗法則：Don't Repeat Yourself。如果代碼的一部分發生了變化（可能是爲了修復一個bug），則必須更改該錯誤的每一處。它可以變成維修噩夢。

來源

2012-12-25 04:02:17 Makoto

通過查看您的代碼，您可以識別敵人是否存在於集合'敵人'中。所以對於你來說，敵人基本上不是一個不是玩家的人。如果你想執行這個語義，那麼我認爲你不應該逃避isEnemy（）方法。

你可能需要的另一個原因isEnemy（）方法是，如果你看到另一種類型的可能性說盟友。擁有isEnemy（）方法將使該添加變得更簡單和更清晰。

但是，如果上述2條件無效，那就擺脫它。正如他們所說YAGNI :)

來源

2012-12-25 04:32:33 Parvez

冗餘代碼是否可以接受，如果它提高了可讀性？

回答

相關問題