注：本文轉載自外刊IT評論。
好的程式設計原則跟好的系統設計原則和技術實施原則有著密切的聯絡。下面的這些程式設計原則在過去的這些年裡讓我成為了一名優秀的程式設計師，我相信，這些原則對任何一個開發人員來說，都能讓他的程式設計能力大幅度的提高，能讓他開發出可維護性更強、缺陷更少的程式。
我不要自我重複 — 這也許是在程式設計開發這最最基本的一個信條，就是要告訴你不要出現重複的程式碼。我們很多的程式設計結構之所以存在，就是為了幫助我們消除重複(例如，迴圈語句， 函式，類，等等)。一旦程式裡開始有重複現象的出現(例如很長的表示式、一大堆的語句，但都是為了表達相同的概念)，你就需要對程式碼進行一次新的提煉，抽象。http://en.wikipedia.org/wiki/Don%27t_repeat_yourself
提煉原則 — 跟“不要自我重複原則”相關，這一原則是說“程式中任何一段具有功能性的程式碼在原始碼檔案中應該唯一的存在。”http://en.wikipedia.org/wiki/Abstraction_principle_(programming)
保持簡單 — 簡單化(避免複雜)永遠都應該是你的頭等目標。簡單的程式讓你寫起來容易，產生的bug更少，更容易維護修改。http://en.wikipedia.org/wiki/KISS_principle
不要開發你目前用不到的功能 — 除非你真正需要用到它，否則不要輕易加上那些亂七八糟用不到的功能。http://en.wikipedia.org/wiki/YAGNI
用最簡單的方法讓程式跑起來 — 在開發時有個非常好的問題你需要問問自己，“怎樣才能最簡單的讓程式跑起來？”這能幫助我們在設計時讓程式保持簡單。http://c2.com/xp/DoTheSimplestThingThatCouldPossiblyWork.html
不要讓我動腦子 — 這實際上是Steve Krug 關於web介面操作的一本書的書名，但也適用於程式設計。主旨是，程式程式碼應該讓人們花最小的努力就能讀懂和理解。如果一段程式對於閱讀者來說需要花費太多的努力才能理解，那它很可能需要進一步簡化。http://www.sensible.com/dmmt.html
開放/封閉原則 — 程式裡的實體項(類，模組，函式等)應該對擴充套件行為開放，對修改行為關閉。換句話說，不要寫允許別人修改的類，應該寫能讓人們擴充套件的類。http://en.wikipedia.org/wiki/Open_Closed_Principle
為維護者寫程式 — 任何值得你編寫的程式在將來都是值得你去維護的，也許由你維護，也許由他人。在將來，當你不得不維護這些程式時，你對這些程式碼的記憶會基本上跟一個陌生人 一樣，所以，你最好還是當成一直在給別人寫程式。一個有助於你記住這個原則的辦法是“寫程式時時刻記著，這個將來要維護你寫的程式的人是一個有嚴重暴力傾 向，並且知道你住在哪裡的精神變態者”。http://c2.com/cgi/wiki?CodeForTheMaintainer
最少意外原則 — 最少意外原則通常是使用在使用者介面設計上，但這個原則同樣適用於編寫程式。程式程式碼應儘可能的不要讓閱讀者感到意外。也就是說應該遵循編碼規範和常見習慣，按照公認的習慣方式進行組織和命名，不符常規的程式設計動作應該儘可能的避免。http://en.wikipedia.org/wiki/Principle_of_least_astonishment
單一職責原則 — 一個程式碼元件(例如類或函式)應該只執行單一的預設的任務。http://en.wikipedia.org/wiki/Single_responsibility_principle
最小化耦合關係 — 一個程式碼片段(程式碼塊，函式，類等)應該最小化它對其它程式碼的依賴。這個目標通過儘可能少的使用共享變數來實現。“低耦合是一個計算機系統結構合理、設計優秀的標誌，把它與高聚合特徵聯合起來，會對可讀性和可維護性等重要目標的實現具有重要的意義。”http://en.wikipedia.org/wiki/Coupling_(computer_programming)
最大化內聚性 — 具有相似功能的程式碼應該放在同一個程式碼元件裡。
http://en.wikipedia.org/wiki/Cohesion_(computer_science)
隱藏實現細節 — 隱藏實現細節能最小化你在修改程式元件時產生的對那些使用這個元件的其它程式模組的影響。http://en.wikipedia.org/wiki/Information_Hiding
笛米特法則(Law of Demeter) — 程式元件應該只跟它的直系親屬有關係(例如繼承類，內包含的物件，通過引數入口傳入的物件等。) http://en.wikipedia.org/wiki/Law_of_Demeter
避免過早優化 — 只有當你的程式沒有其它問題，只是比你預期的要慢時，你才能去考慮優化工作。只有當其它工作都做完後，你才能考慮優化問題，而且你只應該依據經驗做法來優 化。“對於小幅度的效能改進都不該考慮，要優化就應該是97%的效能提升：過早優化是一切罪惡的根源”—Donald Knuth。http://en.wikipedia.org/wiki/Program_optimization
程式碼複用 — 這不是非常核心的原則，但它跟其它原則一樣非常有價值。程式碼複用能提高程式的可靠性，節省你的開發時間。http://en.wikipedia.org/wiki/Code_reuse
職責分離 — 不同領域的功能應該由完全不同的程式碼模組來管理，儘量減少這樣的模組之間的重疊。 http://en.wikipedia.org/wiki/Separation_of_concerns
擁抱變化 — 這是Kent Beck的《解析極限程式設計:擁抱變化》的副標題，它也是極限程式設計和敏捷開發方法的基本信條之一。很多的其它原則都基於此觀念：面對變化，歡迎變化。事實上，一些經典的軟體工程 原則，例如最小化耦合，就是為了讓程式更容易面對變化。不論你是否採用了極限程式設計方法，這個原則對你的程式開發都有重要意義。