良好的程式設計原則與良好的設計工程原則密切相關。本文總結的這些設計原則，幫助開發者更有效率的編寫程式碼，並幫助成為一名優秀的程式設計師。
1.避免重複原則（DRY – Don’t repeat yourself）
程式設計的最基本原則是避免重複。在程式程式碼中總會有很多結構體，如迴圈、函式、類等等。一旦你重複某個語句或概念，就會很容易形成一個抽象體。
2.抽象原則（Abstraction Principle ）
與DRY原則相關。要記住，程式程式碼中每一個重要的功能，只能出現在原始碼的一個位置。
3.簡單原則（Keep It Simple and Stupid ）
簡單是軟體設計的目標，簡單的程式碼佔用時間少，漏洞少，並且易於修改。
4.避免建立你不要的程式碼 Avoid Creating a YAGNI (You aren’t going to need it)
除非你需要它，否則別建立新功能。
5.儘可能做可執行的最簡單的事（Do the simplest thing that could possibly work）
儘可能做可執行的最簡單的事。在程式設計中，一定要保持簡單原則。作為一名程式設計師不斷的反思“如何在工作中做到簡化呢？”這將有助於在設計中保持簡單的路徑。
6.別讓我思考(Don’t make me think )
這是Steve Krug一本書的標題，同時也和程式設計有關。所編寫的程式碼一定要易於讀易於理解，這樣別人才會欣賞，也能夠給你提出合理化的建議。相反，若是繁雜難解的程式，其他人總是會避而遠之的。
7.開閉原則(Open/Closed Principle)
你所編寫的軟體實體（類、模組、函式等）最好是開源的，這樣別人可以擴充開發。不過，對於你的程式碼，得限定別人不得修改。換句話說，別人可以基於你的程式碼進行擴充編寫，但卻不能修改你的程式碼。
8.程式碼維護(Write Code for the Maintainer)
一個優秀的程式碼，應當使本人或是他人在將來都能夠對它繼續編寫或維護。程式碼維護時，或許本人會比較容易，但對他人卻比較麻煩。因此你寫的程式碼要儘可能保證他人能夠容易維護。用書中原話說“如果一個維護者不再繼續維護你的程式碼，很可能他就有想殺了你的衝動。”
9.最小驚訝原則(Principle of least astonishment)
最小驚訝原則通常是在使用者介面方面引用，但同樣適用於編寫的程式碼。程式碼應該儘可能減少讓讀者驚喜。也就是說，你編寫的程式碼只需按照專案的要求來編寫。其他華麗的功能就不必了，以免弄巧成拙。
10.單一責任原則(Single Responsibility Principle)
某個程式碼的功能，應該保證只有單一的明確的執行任務。
11.低耦合原則(Minimize Coupling)
程式碼的任何一個部分應該減少對其他區域程式碼的依賴關係。儘量不要使用共享引數。低耦合往往是完美結構系統和優秀設計的標誌。
12.最大限度凝聚原則(Maximize Cohesion)
相似的功能程式碼應儘量放在一個部分。
13.隱藏實現細節（Hide Implementation Details）
隱藏實現細節原則，當其他功能部分發生變化時，能夠儘可能降低對其他元件的影響。
14.迪米特法則又叫作最少知識原則(Law of Demeter)
該程式碼只和與其有直接關係的部分連線。（比如：該部分繼承的類，包含的物件，引數傳遞的物件等）。
15.避免過早優化(Avoid Premature Optimization)
除非你的程式碼執行的比你想像中的要慢，否則別去優化。假如你真的想優化，就必須先想好如何用資料證明，它的速度變快了。
“過早的優化是一切罪惡的根源”——Donald Knuth
16.程式碼重用原則（Code Reuse is Good）
重用程式碼能提高程式碼的可讀性，縮短開發時間。
17.關注點分離（Separation of Concerns）
不同領域的功能，應該由不同的程式碼和最小重迭的模組組成。
18.擁抱改變（Embrace Change）
這是Kent Beck一本書的標題，同時也被認為是極限程式設計和敏捷方法的宗旨。
許多其他原則都是基於這個概念的，即你應該積極面對變化。事實上，一些較老的程式設計原則如最小化耦合原則都是為了使程式碼能夠容易變化。無論你是否是個極限程式設計者，基於這個原則去編寫程式碼會讓你的工作變得更有意義。
作者簡介：Christopher Diggins是加拿大一位有25年程式設計經驗的資深技術人員，曾效力於Microsoft和Autodesk，並創辦過兩家贏利的網際網路公司。
他是《C++ Cookbook》的作者之一，並自己編寫了一門程式語言Heron。
英文連結：artima