重複的程式碼

說實話，關於這個規範已經提了太多次，只是作者認為，這個規範是書中最重要的規範之一，所以我們就再複習一下。

避免重複，就是避免犯錯並提高撰寫程式的速度。而最明顯的重複情形，自然是一模一樣的程式碼第二次出現。是的，第二次，這可不是我加油添醋。Kent Beck 在「極限程式設計之道」一書中，稱該原則為「一次，就只能一次」。

而稍微隱晦一些的重複，是在不同模組間一再地出現 if/else 或 switch/case 的敘述，並且其具備相同的判斷邏輯。當這種況發生時，我們應該使用多型來消除它。

比上述又再更細微的重複，則是含有類似的演算法，但並沒有共享相同的程式碼。而當遇到此種情境時，我們應該用模版方法 (Template Method) 或 策略模式 (Strategy) 來取代這樣的重複。

在錯誤抽象層次的上的程式碼

建立能劃分「高層次的一般概念」和「低層次細節概念」的抽象模型，是很重要要的工作。

有時我們建立抽象類別來包含高層次概念，並建立其衍伸類別來包含低層次概念。而當我們如此做時，必須要確保所有高層次概念都位於基底類別，所有低層次概念都在衍伸類別中。我們希望高階與低階的概念能夠明確分開，例如常數、變數等與實作細節有關的概念，都不該出現在抽象概念中。基底類別不應該知道任何的實作細節。

而既然抽象概念的基底類別不該知道細節的衍伸類別，當我們看到基底類別相依於其衍伸類別時，我們也可以很清楚地嗅出，這裡的程式碼具有明顯地異味。

過多的資訊

某些時候，越少越好。

一個定義良好的模組只具有少量的介面，可以花費少量氣力便完成大量的任務；反之，定義不良的模組，則會提供廣泛及深入的介面，導致花費許多時間卻只完成少量的事情。

軟體開發者應要學會限制類別及模組中的介面數量。而類別中的方法越少越好，擁有的實體變數越少越好。一個函式知道的變數越少越好。

而這些避免異味的準則，也在在呼應了前面講述類別的章節時，提到過要將不夠相關的實體變數、方法抽離出來，成為一個新的微型類別，好提高每個類別的凝聚性，並降低耦合性。

被遺棄的程式碼

這裡所說的遺棄，不同於前天所指────被註解不用的程式碼，而是指雖然存在但永遠不會被執行的程式碼。那些 if 敘述中絕不會成立的判斷式主體中，或在 try/catch 永遠不會被拋出的錯誤處理內，當我們看見時，應該改寫或移除它，因為它將不會更隨著程式的更迭而變化，於是漸漸發臭發酸。

除了程式敘述主體，那些用不著的建構子，不被使用的變數，不被呼叫的函式，都應該被移除。因為它們除了弄亂程式碼的組織性，沒有絲毫作用。

不一致性

記得嗎？最少驚奇原則。
小心選擇我們撰寫程式碼的慣例，一旦決定了，就要小心且持續地遵守它。這些慣例可能是變數或函式的命名原則、撰寫程式碼的風格等等。運用簡單且一致的原則，能夠幫助我們的程式碼被閱讀及理解。