[閱讀筆記] 易讀程式之美 (Part 2)

1. C++的創造者Bjarne Stroustrup說，在我的個人經驗裡，do / while 敘述經常是錯誤與誤解的來源，我寧願把條件式列在最前面，總而言之，我會盡量避免使用do / while 敘述
2. 修改程式碼時要以全新的角度審視，退一步以整體的角度考慮程式碼
3. 盡量消除loop中的巢狀結構，因為巢狀結構可讀性較差
4. 程式碼的表示式越大，就越難理解。所以，要將巨大表示式分解為更容易消化的大小
5. 寫法很酷的程式碼，經常會對後續使用程式的人造成困擾
6. 對邏輯表示式使用De Morgan’s Law，有時能將boolean 表示式以更清晰的方式表達，比較簡單的記法是，把not分配到各項，再反轉and / or。如，if( !(a && !b)) 改寫成 if (!a || b)，if ( !(file_exists && !is_protected)) 改寫成 if (( !file_exists || is_protected))
7. 濫用變數會造成三個問題：變數越多越難同時記住所有變數；變數存活的範圍越大，就必須記得越久；變數越常改變，越難記得目前的數值
8. 工程就是將大問題分解成小問題在將小問題的解答組合成原本大問題的解答在程式碼應用這個原則能讓程式更強固也更易於閱讀
9. 抽離程式碼為獨立函數，這是程式設計師每天都在做的工作
10. 函式庫提供的介面要夠簡潔，不要太多參數，也不要有太多的設定程序，用起來不要有額外的負擔。讓程式碼看起來更佳優雅，也更簡單與強而有力
11. 程式碼應該組織為一次只做一件事
12. 如果程式碼很難閱讀，試著列出執行的工作，某些工作可以輕易的抽離為函數或類別，其他部分可以成為函數內邏輯的段落。分離工作細節的形式並不重要，重要的是彼此分咧，真正困難的部份在於列出所有函數執行的小工作
13. 愛因斯坦曾說：除非能解釋讓祖母了解，不然就不算真正了解
14. 可讀性最高的程式碼就是完全沒有程式碼
15. 程式設計師常會低估實作功能需要的功夫，會很理想的估計實作粗糙原形所需的時間，忽略後續維護、文件以及對程式碼增加的額外負擔
16. 程式設計師一般會高估專案正正需要的核心功能，造成許多功能來不及完成，或祇是增加應用程式的複雜度
17. 消除不必要的需求、簡化問題非常重要，重新思考需求，在仍然能達到目的的情況下，改為解決簡化過的問題
18. 避免過度設計
19. 當任何系統成長時，維持系統所需的複雜度會以更快的速度成長
20. 盡量維持程式碼小而美
21. 測試應該易於閱讀，以便其他人可以放心地修改或其加入其他測試。測試程式碼與非測試用程式碼一樣重要。
22. 依據一般設計原則，應該「對使用者隱藏不重要的細節，凸顯重要的細節」
23. 錯誤訊息應該盡量清楚地提供有幫助的資訊，有時候，「自行手工打造」印出所需的訊息，會是最好的方式
24. 測試都時候，應該挑選能完整執行程式碼所需之最簡單的集合作為輸入值。優先使用簡單、明確但能達到測試效果的輸入值
25. 一般來說，如果在設計程式的時候體認到，「嗯，之後這段會很難測試」，這就是個停止考慮這種設計的好理由
26. 100行容易讀的程式，比起50行艱澀難懂的程式碼要來得好