程式碼大全書評
https://movie.douban.com/review/7836312/

程式碼大全 摘記
https://blog.csdn.net/roofalison/article/details/5651808
https://blog.csdn.net/puma_dong/article/details/45345397

設計的啟發式方法的總結

• 形成一致的抽象
• 封裝實現細節
• 資訊隱藏

類的介面應該儘可能少地暴露其內部工作機制。
好的類的介面就像是冰山的尖兒一樣，讓類的大部分內容都不會暴露出來。 P93

請養成問 我該隱藏些什麼？的習慣，你會驚奇地發現，有很多棘手的設計難題都會在你面前化解。P97

程式設計愛好者和專業程式設計師之間最大的區別之一便是從迷信到理解的轉變。這裡所說的“迷信”並不是指一個程式會在月圓之時讓你心生驚恐或產生什麼莫名其妙的錯誤。Z9P230
如果你沒有陷入這種“拼湊加編譯”的怪圈，那就在你覺得合適的時候再去編譯吧。Z9P231

用布林變數來簡化複雜的判斷Z12P301
使用具名常量非常有助於程式的維護
 避免使用文字量，即使是“安全”的Z12P308

作為一天普遍性選擇，要讓程式易於自上而下閱讀，而不是讓讀者的目光跳來跳去。Z14P351 
把相關的語句組織在一起，就近原則Z14P352

每個團隊裡也許都有一個這樣的程式設計師,他總會遇到無窮的問題:不聽話的機器,奇怪的編譯器錯誤,月圓時才會出現的程式語言的隱藏缺陷,失效的資料,忘記做的重要發動,一個不能正常儲存程式的瘋狂的編輯器.這就是迷信式程式設計. Z23P539

如果想讓自己的生活潦倒，讓自己的程式碼質量一塌糊塗的最好方法，就是不懂裝懂地動手修補程式缺陷。Z23P550

將編譯器的警告級別設定為最高階，儘可能不放過任何一個警告，然後修正編譯器所報告的全部錯誤。Z23P557

首先為人寫程式，其次才是機器 Z34P841
基於問題域程式設計Z34P845

先以虛擬碼編寫類再改用實際程式碼Z33P834
編譯前認真檢查程式碼Z33P834