這是摘抄自《編程珠璣II》第六章的一些比較有趣的話，加上了一些自己的感想或理解。
編碼篇
- 迴歸測試能將測試區間減半。
—Larry Bernstein，貝爾通信研究院 - Π秒就是一個納世紀。
—Tom Duff，貝爾實驗室 - 如果還沒想清楚，就用蠻力算法吧。（自己想了之後，蠻力之前，請別人幫自己想想）
—Ken Thompson，貝爾實驗室 - 避免不對稱結構。
—Andy Huber，Data General公司 - 你用英語都寫不出來的東西就別指望用代碼寫了。
—Peter Halpern，貝爾實驗室 - 如果代碼和註釋不一致，那很可能兩者都錯了。
—Norm Schryer，貝爾實驗室 - 如果你發現特殊情況太多，那你肯定用錯方法了。（保持簡單的設計，解決一般性問題，比解決特殊問題更容易）
—Craig Zerouni，Computer FX公司（英國倫敦） - 先把數據結構搞清楚，程序其餘部分自現。（所有的算法，都與相應的數據結構配套，選擇一種合適的數據結構，好的算法纔可能出現）
—David Jones，荷蘭阿森 - 代碼寫得越急，程序跑得越慢。（先思考，看看是否有更好的算法，編碼的過程寫出便於編譯器進行優化的代碼）
—Roy Carlson，威斯康星大學
用戶界面篇
- 【最小驚異原則】儘可能讓用戶界面風格一致和可預測。（人們的習慣是很難突然改變的，如果用戶做到了，很可能是不愉快地做到的，更可能的是用戶根本不想去做；如果要讓用戶等待，要麼告知用戶還要等待多久，要麼主動讓用戶忘了等待這件事）
- 計算機生成的輸入通常會讓一個原本設計接收手工輸入的程序不堪重負。（嗯，這肯定不是在說程序崩潰，而是計算機輸入太快了）
—Dennis Ritchie，貝爾實驗室 - 80%的表單會要你回答沒有必要的問題。（保持簡單的設計吧）
—Mike Garey，貝爾實驗室 - 不要讓用戶提供那些系統已經知道的信息。（計算機能做的事，就別用手工做了，即使那些手工不是你的）
—Rick Lemons，Cardinal數據系統公司 - 所有數據集的80%中，有95%的信息量都可以用清晰的圖表示。
—William S. Cleveland，貝爾實驗室
調試篇
- 在我所有的程序錯誤中，有80%是語法錯誤。剩下的20%裏，80%是簡單的邏輯錯誤。在剩下的4%裏，80%是指針錯誤。只有餘下的0.8%纔是困難的問題。
—Marc Donner，IBM沃森研究中心 - 在系統測試階段找出並修正錯誤，要比開發者自己完成這一工作多付出兩倍的努力。而當系統已經交付使用之後找出並修正一個錯誤，要比系統測試階段多付出9倍的努力。因此，請堅持讓開發者進行單元測試吧。
—Larry Bernstein，貝爾通信研究院 - 不要站着調試程序。那會使得你的耐心減半，而你需要的事全神貫注。
—Dave Storer，艾奧瓦州錫達拉皮茲 - 測試只能證明程序有錯誤，而不能證明程序沒有錯誤。
—Edsger W. Dijkstra，德克薩斯大學 - 別在註釋裏陷得太深——註釋很可能會誤導你，你要調試的只是代碼。（所以最重要的要理解要解決的問題是什麼，那樣就可以知道代碼和註釋哪個更可靠）
—Dave Storer，艾奧瓦州錫達拉皮茲 - 新系統的每一個新用戶都可能發現一類新的錯誤。（新用戶發現錯誤不是壞事，說明你的用戶正在增加，如果想要更多，愉快地修復吧）
—Brian Kernighan，貝爾實驗室 - 東西沒壞，就別亂修。
—羅納德.里根，加州聖巴巴拉 - 【維護者箴言】如果我們沒有能力修好它，我們就會告訴你他根本就沒壞。（最好別這樣，最起碼指出錯誤在哪裏，或明確給出正確的使用方式）
—Walt Weir，美國陸軍中校 - 修正程序的第一步是要先重視這個錯誤。（然後理解這個錯誤，接下來纔是修正）
—Tom Duff，貝爾實驗室
性能篇
- 【程序優化第一法則】不要優化。
- 【程序優化第二法則——僅對專家適用】還是不要優化。
—Michael Jackson，Michael Jackson系統公司 - 對於那些快速算法，我們總是可以拿一些速度差不多但是更容易理解的算法來替代它們。（如果可以，爲什麼不呢）
—Douglas W. Jones，艾奧瓦大學 - 在一個非I/O密集型的程序中，超過一半的運行時間是花在不足4%的代碼上的。
—Don Knuth，斯坦福大學 - 在一些機器上，間接尋址比基址尋址更慢，所以請把結構體或記錄中最常用的成員放在最前面。
—Mike Morton，馬薩諸塞州波士頓 - 在優化一個程序之前，請先用性能監視工具找到程序的“熱點”。
—Mike Morton，馬薩諸塞州波士頓 - 【代碼規模守恆定律】當你爲了加速，把一頁代碼變成幾條簡單的命令時，請不要忘了增加註釋，以使源碼的行數保持爲一個常量。
—Mike Morton，馬薩諸塞州波士頓 - 如果程序員自己模擬實現一個構造比編譯器本身實現的那個構造還要快，那編譯器作者也太失敗了。
—Guy L. Steele，Jr.，Tartan實驗室 - 要加速一個I/O密集型的程序，請首先考慮所有的I/O。消除那些不必要的或冗餘的I/O，並使餘下的部分儘可能地快。
—David Martin，賓夕法尼亞州諾里斯敦 - 大多數的彙編語言都有循環操作，用一條指令進行一次比較分支；儘管這條指令是爲循環設計的，但在做普通的比較時也往往能派上用場，而且很有效。
—Guy L. Steele，Jr.，Tartan實驗室
文檔篇
- 【否定測試】如果一句話反過來就必然不成立，那就根本沒必要把這句話放進文檔。
—Bob Martin，AT&T公司 - 當你試圖解釋一條命令，一個語言特性或是一種硬件的時候，請首先說明它要解決什麼問題。
—David Martin，賓夕法尼亞州諾里斯敦 - 【一頁原則】一個{規格說明、設計、過程、測試計劃}如果不能在一頁8.5英寸×11英寸的紙上寫明白的話，那麼這個東西別人就沒辦法理解。
—Mark Ardis，王安公司 - 紙上的工作沒結束，整個工作也就還沒結束。
軟件管理篇
1． 系統的結構反映出構建該系統的組織的結構。
—Richard E. Fairley
2． 別堅持做哪些沒用的事。（通用語）
3． 【90-90法則】前90%的代碼佔用了90%的預定開發時間，餘下的10%代碼又花費了90%的預定開發時間。
—Tom Cargill，貝爾實驗室
4. 只有不到10%的代碼用於完成這個程序表面上的目的，餘下的都在處理輸入輸出，數據驗證、數據結構維護等家務活。
—Marry Shaw，卡內基-梅隆大學
5. 正確的判斷來源於經驗，然而經驗來源於錯誤的判斷。（別怕錯誤）
—Fred Brooks，北卡羅來納大學
6. 如果有人基本做出了你想要的東西，你就沒必要自己寫一個新程序。就算你非寫不可，也請儘可能多地利用現有的代碼。（嗯，工作中可以這樣，如果是要學習理解，自己動手吧）
—Richard Hill，惠普公司（瑞士日內瓦）
7. 代碼能借用就借用。（若理解了可以這樣）
—Tom Duff，貝爾實驗室
8. 與客戶保持良好的關係可以使生產率加倍。
—Larry Bernstein，貝爾通信研究院
9. 把一個現有成熟程序轉移到一種新語言或者新平臺，只需要原來開發的十分之一的時間、人力、成本。
—Douglas W. Jones，艾奧瓦大學
10. 那些用手做就已經很快了的事情，就別用手做了。
—Richard Hill，惠普公司（瑞士日內瓦）
11. 那些能用計算機迅速解決的問題，就別用手做了。
—Tom Duff，貝爾實驗室
12. 我想寫的程序不只是程序，而且是會寫程序的程序。（這個目標很激動人心，值得追求，想偷懶，先變得更勤快）
—Dick Sites，DEC公司
13. 【Brooks原型定理】計劃好拋棄一個原型，這是遲早的事。（迭代初期生成的產品應該是最終系統的一部分，我更傾向下一條）
—Fred Brooks，北卡羅來納大學
14. 如果開始就打算拋棄一個原型，那恐怕你得拋棄兩個。
—Craig Zerouni，Computer FX公司（英國倫敦）
15. 原型方法可以使系統開發的工作量減少40%。
—Larry Bernstein，貝爾通信研究院
16. 【Thompson望眼鏡學徒定理】先做一個4英寸鏡片的9（望遠鏡），再做一個6英尺鏡片的，這比直接做6英尺鏡片更省時間。
—Bill McKeeman，王安公司
17. 拼命幹活無法取代理解。（理解問題，然後理解問題，然後一邊幹活，一邊理解）
—H. H. Williams，加州奧克蘭
18. 做事應該先做最難的部分。如果最難的部分無法做到，那還在簡單的部分上浪費時間幹嘛？一旦困難的地方搞定了，那你就勝利在望了。
19. 做事應該先做最簡單的部分。你開始所預想的簡單部分，做起來可能是很有難度的。一旦你把簡單的部分都做好了，你就可以全力攻克最難的部分了。（先做簡單的事情利於理解問題）
—Al Schapira，貝爾實驗室
其他
- 【Sturgeon定律】毫無疑問，90%的軟件都沒什麼用。這是因爲對任何東西而言，90%都是沒什麼用的。
——Marry Shaw，卡內基-梅隆大學 - 對計算機撒謊是要受到懲罰的。
——Perry Farrar，馬里蘭州 - 如果不要求系統可靠的話，它可能做任何事情了。
——H. H. Williams，加州奧克蘭 - 一個人的常量就是另一個人的變量。（這句話在生活中不也可以用嗎？）
——Susan Gerhart，Microelectronics and Computer Technology公司 - 一個人的數據就是另一個人的程序。
——Guy L. Steele，Jr.，Tartan實驗室 - 【KISS法則】用最簡單、最笨的方法做事。（崇尚簡單，但別被“笨”字騙了，思考創造性的方法吧，大智若愚不是做出來的，而是看起來的樣子）
結語
別輕信那些看似聰明的法則。（選擇一些能說服自己的法則去實踐，法則是可以相悖的，但是不應該因爲它們的存在而搖擺自己的決策）
——Joe Condon，貝爾實驗室