版本1
- 讓每個程序就做好一件事。如果有新任務，就重新開始谦絮，不要往原程序中加入新功能而搞得復雜。
- 假定每個程序的輸出都會成為另一個程序的輸入洁仗，哪怕那個程序還是未知的层皱。輸出中不要有無關的信息干擾。避免使用嚴格的分欄格式和二進制個數(shù)輸入赠潦。不要堅持使用交互性輸入叫胖。
- 盡可能早地將設計和編譯的軟件投入試用，哪怕時操作系統(tǒng)也不例外她奥，理想情況下瓮增，應該時在幾星期內(nèi)。對拙劣的代碼別猶豫方淤，扔掉重寫钉赁。
- 優(yōu)先試用工具而不是拙劣的幫助來減輕編程任務的負擔。工欲善其事携茂，必先利其器你踩。
總結(jié)：Unix哲學時這樣的：一個程序只做一件事，并做好讳苦。程序要能協(xié)作带膜。程序要能處理文本流，因為這是最通用的接口鸳谜。
版本2
- 你無法判定程序會在什么地方耗費運行時間膝藕。瓶頸經(jīng)常出現(xiàn)在想不到的地方，所以別急于胡亂找個地方改代碼咐扭，除非你已經(jīng)證實那兒就是瓶頸所在芭挽。
- 估量。在你沒對代碼進行估量蝗肪，特別時沒找到最耗時的那部分之前袜爪，別去優(yōu)化速度。
- 花哨的算法在n很小時通常很慢薛闪，而n通常很小辛馆。花哨算法的常數(shù)復雜度很大豁延。除非你確定n總是很大昙篙，否則不要用花哨算法（即使n很大腊状，也優(yōu)先考慮原則2）。
- 花哨的算法比簡單算法更容易出bug苔可、更難實現(xiàn)缴挖。盡量試用簡單的算法配合簡單的數(shù)據(jù)結(jié)構(gòu)。（拿不準就窮舉）
- 數(shù)據(jù)壓倒一切硕蛹。如果已經(jīng)選擇了正確的數(shù)據(jù)結(jié)構(gòu)并且把一切都組織的井井有條醇疼，正確的算法也就不言而明。編程的核心時數(shù)據(jù)結(jié)構(gòu)法焰，而不是算法秧荆。
- 沒有原則6。
版本3
- 模塊原則：使用簡潔的接口拼合簡單的部件埃仪。
- 清晰原則：清晰勝于技巧乙濒。
- 組合原則：設計時考慮拼接組合。
- 分離原則：策略同機制分離卵蛉，接口同引擎分離颁股。
- 簡潔原則：設計要簡潔，復雜度能低則低傻丝。
- 吝嗇原則：除非確無他法甘有，不要編寫龐大的程序。
- 透明性原則：設計要可見葡缰，以便審查和調(diào)試亏掀。
- 健壯原則：健壯源于透明與簡潔。
- 表示原則：把知識疊入數(shù)據(jù)以求邏輯質(zhì)樸而健壯泛释。
- 通俗原則：接口設計避免標新立異滤愕。
- 緘默原則：如果一個程序沒什么好說的，就沉默怜校。
- 補救原則：出現(xiàn)異常時间影，馬上退出并給出足夠錯誤信息。
- 經(jīng)濟原則：寧花機器一分茄茁，不花程序員一秒魂贬。
- 生成原則：避免手工hack，盡量編寫程序去生成程序裙顽。
- 優(yōu)化原則：雕琢前先要有原型付燥，跑之前先學會走。
- 多樣原則：絕不相信所謂的“不二法門”的斷言锦庸。
- 擴展原則：設計著眼未來机蔗，未來總比預想來的塊蒲祈。
Unix哲學之一言以蔽之
kiss-Keep It Simple, Stupid!
應用Unix哲學（一些例子）
- 只要可行甘萧，一切都應該做成與來源和目標無關的過濾器
- 數(shù)據(jù)流盡可能文本化（這樣可以使用標準工具來查看和過濾）
- 數(shù)據(jù)庫部署和應用協(xié)議盡可能文本化（讓人可以閱讀和編輯）
- 復雜的前端（用戶界面）和后端應該涇渭分明
- 當且僅當只用一門語言編程會提高程序復雜度時萝嘁，混用語言編程才比單一語言編程來得好
- 寬收嚴發(fā)（對接收的東西要包容，對輸出的東西要嚴格）
- 過濾時扬卷，不需要丟失的信息決不丟
- 小就是美牙言。在確保完成任務的基礎上，程序功能盡可能少怪得。
