代碼大全 重要觀點集錦
代碼大全書評
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
代碼大全 重要觀點集錦