所以，如何寫出一手好代碼?

良好的代碼更易于閱讀、理解、調試和修改，最重要的是它的缺陷也更少。顯然，編寫良好的代碼需要更多的時間，但是從長遠來看，它也具有更多的價值，因為這降低了維護的成本，而且具有更好的可重用性。

事實上，我們可以將好的代碼等同為可重用的代碼，這也是本篇文章羅列的許多技巧背后的驅動原則。作為一個要實現特定功能的開發者，代碼可以實現你的短期目標，但如果沒有其他人希望重用它(包括未來的自己)，這些代碼一定會缺失某些東西。無論它是太復雜，還是太具體，在不同情況下都有很大可能會出錯，或者不被其他開發者信任。

我發現，只要嘗試堅持將下面的最佳實踐應用于你編寫的所有代碼(包括你的實驗和原型)，無論你現在的經驗水平如何，都會編寫出更好的代碼。

1. 遵循單一職責原則

函數是程序員的工具中最重要的抽象形式。它們能更多地被重復使用，你需要編寫的代碼就越少，代碼也因此變得更可靠。較小的函數遵循單一職責原則更有可能被重復使用。

2. 盡量減少共享狀態

你應該盡量減少函數之間的隱式共享狀態，無論它是文件作用域的變量還是對象的成員字段，這有利于明確要求把值作為參數。當能明確地顯示函數需要什么才可以產生所需的結果時，代碼會變得更容易理解和重用。

對此的一個推論是，在一個對象中，相對于成員變量，你更應該優先選擇靜態的無狀態變量 (static stateless variables)。

3. 將“副作用”局部化

理想的副作用(例如：打印到控制臺、日志記錄、更改全局狀態、文件系統操作等)應該被放置到單獨的模塊中，而不是散布在整個代碼里面。函數中的一些“副作用”功能往往違反了單一職責原則。

4. 優先使用不變的對象

如果一個對象的狀態在其構造函數中僅被設置一次，并且從不再次更改，則調試會變得更加容易，因為只要構造正確就能保持有效。這也是降低軟件項目復雜性的最簡單方法之一。

5. 多用接口少用類

接收接口的函數(或 C++ 中的模板參數和概念)比在類上運行的函數更具可重用性。

6. 對模塊應用良好的原則

尋找機會將軟件項目分解成更小的模塊(例如庫和應用程序)，以促進模塊級別的重用。對于模塊，應該遵循的一些關鍵原則是：

• 盡可能減少依賴
• 每個項目應該有一個明確的職責
• 不要重復自身
• 你應該努力使你的項目保持小巧和明確。

7. 避免繼承

在面向對象編程中，繼承 —— 特別是和虛擬函數結合使用時，在可重用性方面往往是一條死胡同。我很少有成功的使用或編寫重載類的庫的經歷。

8. 將測試作為設計和開發的一部分

我不是測試驅動開發的堅定分子，但開始編碼時先編寫測試代碼會使得代碼十分自然地遵循許多指導原則。這也有助于盡早發現錯誤。不過要注意避免編寫無用的測試，良好的編碼實踐意味著更高級別的測試(例如單元測試中的集成測試或特征測試)在揭示缺陷方面更有效。

9. 優先使用標準庫而不是手寫的

我經常看到更好版本的 std::vector 或 std::string，但這幾乎總是浪費時間和精力。一個明顯的事實是 —— 你正在為一個新的地方引入 bug，其他開發者也不太可能重用你的代碼，因為沒有被廣泛理解、支持和測試。

10. 避免編寫新的代碼

這是每個程序員都應遵循的最重要的教誨：最好的代碼就是還沒寫的代碼。你寫的代碼越多，你將遇到的問題就越多，查找和修復錯誤就越困難。

在寫一行代碼之前先問一問自己，有沒有一個工具、函數或者庫已經實現了你所需要的功能?你真的需要自己實現這個功能，而不是調用一個已經存在的功能嗎?

寫在最后的話

我發現編程是一門與學習藝術或運動非常相似的技能，你通過刻意的練習和從別人的經驗中學習會得到更好的結果。不斷提升你產出的代碼質量有助于你成為更優秀的程序員。