本文是從"The Principles of Good Programming"這篇文章翻譯而來。
好的編程原則跟好的系統(tǒng)設(shè)計(jì)原則和技術(shù)實(shí)施原則有著密切的聯(lián)系。下面的這些編程原則在過去的這些年里讓我成為了一名優(yōu)秀的程序員，我相信，這些原則對(duì)任何一個(gè)開發(fā)人員來說，都能讓他的編程能力大幅度的提高，能讓他開發(fā)出可維護(hù)性更強(qiáng)、缺陷更少的程序。
我不要自我重復(fù) 這也許是在編程開發(fā)這最最基本的一個(gè)信條，就是要告訴你不要出現(xiàn)重復(fù)的代碼。我們很多的編程結(jié)構(gòu)之所以存在，就是為了幫助我們消除重復(fù)(例如，循環(huán)語句，函數(shù)，類，等等)。一旦程序里開始有重復(fù)現(xiàn)象的出現(xiàn)(例如很長(zhǎng)的表達(dá)式、一大堆的語句，但都是為了表達(dá)相同的概念)，你就需要對(duì)代碼進(jìn)行一次新的提煉，抽象。
http://en.wikipedia.org/wiki/Don%27t_repeat_yourself
提煉原則 跟不要自我重復(fù)原則相關(guān)，這一原則是說程序中任何一段具有功能性的代碼在源代碼文件中應(yīng)該唯一的存在。
http://en.wikipedia.org/wiki/Abstraction_principle_(programming)
保持簡(jiǎn)單 簡(jiǎn)單化(避免復(fù)雜)永遠(yuǎn)都應(yīng)該是你的頭等目標(biāo)。簡(jiǎn)單的程序讓你寫起來容易，產(chǎn)生的bug更少，更容易維護(hù)修改。
http://en.wikipedia.org/wiki/KISS_principle
不要開發(fā)你目前用不到的功能 除非你真正需要用到它，否則不要輕易加上那些亂七八糟用不到的功能。
http://en.wikipedia.org/wiki/YAGNI
用最簡(jiǎn)單的方法讓程序跑起來 在開發(fā)時(shí)有個(gè)非常好的問題你需要問問自己，怎樣才能最簡(jiǎn)單的讓程序跑起來？這能幫助我們?cè)谠O(shè)計(jì)時(shí)讓程序保持簡(jiǎn)單。
http://c2.com/xp/DoTheSimplestThingThatCouldPossiblyWork.html
不要讓我動(dòng)腦子 這實(shí)際上是Steve Krug 關(guān)于web界面操作的一本書的書名，但也適用于編程。主旨是，程序代碼應(yīng)該讓人們花最小的努力就能讀懂和理解。如果一段程序?qū)τ陂喿x者來說需要花費(fèi)太多的努力才能理解，那它很可能需要進(jìn)一步簡(jiǎn)化。
http://www.sensible.com/dmmt.html
開放/封閉原則 程序里的實(shí)體項(xiàng)(類，模塊，函數(shù)等)應(yīng)該對(duì)擴(kuò)展行為開放，對(duì)修改行為關(guān)閉。換句話說，不要寫允許別人修改的類，應(yīng)該寫能讓人們擴(kuò)展的類。
http://en.wikipedia.org/wiki/Open_Closed_Principle
為維護(hù)者寫程序 任何值得你編寫的程序在將來都是值得你去維護(hù)的，也許由你維護(hù)，也許由他人。在將來，當(dāng)你不得不維護(hù)這些程序時(shí)，你對(duì)這些代碼的記憶會(huì)基本上跟一個(gè)陌生人一樣，所以，你最好還是當(dāng)成一直在給別人寫程序。一個(gè)有助于你記住這個(gè)原則的辦法是寫程序時(shí)時(shí)刻記著，這個(gè)將來要維護(hù)你寫的程序的人是一個(gè)有嚴(yán)重暴力傾向，并且知道你住在哪里的精神變態(tài)者。
http://c2.com/cgi/wiki?CodeForTheMaintainer
最少意外原則 最少意外原則通常是使用在用戶界面設(shè)計(jì)上，但這個(gè)原則同樣適用于編寫程序。程序代碼應(yīng)盡可能的不要讓閱讀者感到意外。也就是說應(yīng)該遵循編碼規(guī)范和常見習(xí)慣，按照公認(rèn)的習(xí)慣方式進(jìn)行組織和命名，不符常規(guī)的編程動(dòng)作應(yīng)該盡可能的避免。
http://en.wikipedia.org/wiki/Principle_of_least_astonishment
單一職責(zé)原則 一個(gè)代碼組件(例如類或函數(shù))應(yīng)該只執(zhí)行單一的預(yù)設(shè)的任務(wù)。
http://en.wikipedia.org/wiki/Single_responsibility_principle
最小化耦合關(guān)系 一個(gè)代碼片段(代碼塊，函數(shù)，類等)應(yīng)該最小化它對(duì)其它代碼的依賴。這個(gè)目標(biāo)通過盡可能少的使用共享變量來實(shí)現(xiàn)。低耦合是一個(gè)計(jì)算機(jī)系統(tǒng)結(jié)構(gòu)合理、設(shè)計(jì)優(yōu)秀的標(biāo)志，把它與高聚合特征聯(lián)合起來，會(huì)對(duì)可讀性和可維護(hù)性等重要目標(biāo)的實(shí)現(xiàn)具有重要的意義。
http://en.wikipedia.org/wiki/Coupling_(computer_programming)
最大化內(nèi)聚性 具有相似功能的代碼應(yīng)該放在同一個(gè)代碼組件里。
http://en.wikipedia.org/wiki/Cohesion_(computer_science)
隱藏實(shí)現(xiàn)細(xì)節(jié) 隱藏實(shí)現(xiàn)細(xì)節(jié)能最小化你在修改程序組件時(shí)產(chǎn)生的對(duì)那些使用這個(gè)組件的其它程序模塊的影響。
http://en.wikipedia.org/wiki/Information_Hiding
笛米特法則(Law of Demeter)程序組件應(yīng)該只跟它的直系親屬有關(guān)系(例如繼承類，內(nèi)包含的對(duì)象，通過參數(shù)入口傳入的對(duì)象等。)
http://en.wikipedia.org/wiki/Law_of_Demeter
避免過早優(yōu)化 只有當(dāng)你的程序沒有其它問題，只是比你預(yù)期的要慢時(shí)，你才能去考慮優(yōu)化工作。只有當(dāng)其它工作都做完后，你才能考慮優(yōu)化問題，而且你只應(yīng)該依據(jù)經(jīng)驗(yàn)做法來優(yōu)化。對(duì)于小幅度的性能改進(jìn)都不該考慮，要優(yōu)化就應(yīng)該是97%的性能提升：過早優(yōu)化是一切罪惡的根源Donald Knuth。
http://en.wikipedia.org/wiki/Program_optimization
代碼復(fù)用 這不是非常核心的原則，但它跟其它原則一樣非常有價(jià)值。代碼復(fù)用能提高程序的可靠性，節(jié)省你的開發(fā)時(shí)間。
http://en.wikipedia.org/wiki/Code_reuse
職責(zé)分離 不同領(lǐng)域的功能應(yīng)該由完全不同的代碼模塊來管理，盡量減少這樣的模塊之間的重疊。
http://en.wikipedia.org/wiki/Separation_of_concerns
擁抱變化 這是Kent Beck的一本書的副標(biāo)題，它也是極限編程和敏捷開發(fā)方法的基本信條之一。很多的其它原則都基于此觀念：面對(duì)變化，歡迎變化。事實(shí)上，一些經(jīng)典的軟件工程原則，例如最小化耦合，就是為了讓程序更容易面對(duì)變化。不論你是否采用了極限編程方法，這個(gè)原則對(duì)你的程序開發(fā)都有重要意義。