經過多年的積累，我發現，下面這些基本的指導法則，可以幫助我成爲一個更加高效的程序員。
程序設計法則，與設計和工程的原理密切相關。下面這些編程法則幫助我讓我獲益匪淺，所以我想分享給大家，希望也能幫助大家更高效，生產出的代碼更容易維護，並且bug和缺陷更少。
DRY原則
不要重複（Don’t repeat yourself）——程序設計中一個最根本的原則就是要避免重複。許多編程結構（比如循環、函數、類等）的存在就是爲了避免重複。一旦重複（例如，一個長表達式，一系列語句，相同的概念）的話，就會創建一個新的抽象。
抽象原則
“每個在程序中有意義的功能片段應該只在源代碼的一處地方實現。”
KISS（Keep it simple, stupid!）原則
簡單性（避免複雜性）應該永遠當作是一個重要的目標。寫簡單的代碼，不但花費的時間少，錯誤少，而且修改起來也容易。
避免創建YAGNI（You aren’t going to need it）原則
只有當你需要的時候纔去添加額外的功能，不需要就不要畫蛇添足。
方法要最簡單，效果要一樣好
在編程時，我們需要問問自己：“有沒有最簡單的完成任務的途徑？”這有助於我們保持一直行走在簡約設計的道路上。
不要讓我思考
這實際上是由Steve Krug寫的一本書的書名。關鍵要點是，代碼應該儘可能地易於閱讀和理解。如果閱讀人需要大量的思考才能理解代碼，那麼或許這代碼還需要被簡化。
開/閉原則
軟件實體（類，模塊，函數等）在擴展時應該開放，在修改時應該關閉。換句話說，你寫的類大家可以擴展，但不能修改。
爲維護者寫代碼
值得寫的代碼要保證將來一定值得維護。未來的你由於經歷的代碼太多，也許再回過頭來看這些代碼的時候，也和其他人一樣，已經成爲了一個完全的陌生人。請記住，“寫代碼的時候，就假設將來要維護的人是個知道你住在哪裏的暴力型精神病患者吧。”
最小驚訝原則
最小驚訝原則通常引用於用戶界面方面，但這一原則也適用於編寫代碼。代碼應該儘可能地不要讓閱讀者驚訝。遵守標準約定，註釋說什麼代碼就做什麼，命名是什麼意思代碼就是什麼意思，儘可能地避免驚訝導致的潛在的負面影響。
單一職責原則
代碼（如類或函數）的組成部分執行的應該是一個單一的明確的任務。
最小化耦合原則
代碼的任何部分（代碼塊，函數，類等）都應該儘量減少對其他代碼的依賴。這可以通過儘量不要使用共享變量來實現。“低耦合常常是計算機系統構造良好和設計良好的標誌，並且當和高內聚力相結合的話，還可以大大支持高可讀性和可維護性的整體目標。”
最大化內聚原則
具有相似功能的代碼應該放在同一個組件內。
隱藏實現細節原則
隱藏實現細節，允許在改變代碼組件的實現的同時，最低限度地減少對使用該組件的其他模塊的影響。
得墨忒耳定律
代碼組件應該只和它們的直接關係（如，繼承的類，包含的對象，通過參數傳遞的對象等）溝通。
避免過早優化原則
除非代碼開始工作，否則甚至就不要有優化的念頭。只有當你必須要優化的時候，才能藉助實戰數據的幫助。 “我們一定要有大局觀：過早的優化是萬惡之源”——Donald Knuth。
重用代碼纔是好代碼
這和任何其他法則一樣之精闢。重用代碼可以提高代碼的可靠性，並減少開發時間。
關注點分離原則
不同的功能區域應該由明顯的重疊最小的代碼模塊進行管理。
擁抱變化原則
這是Kent Beck寫的一本書的副標題，也被認爲是極端編程和通用敏捷方法的原則。許多其他原則都基於這個理念：你應該期待和歡迎變化。事實上，很多古老的軟件工程法則，例如最小化耦合原則，就是和讓代碼變得更容易改變是直接相關的。無論你是不是一個極端編程的實踐者，這種寫代碼的方法真的很有意義。
本文分享自：http://www.codeceo.com/article/18-good-programming-principles.html