《Code Craft》 筆記 - 如何寫出良好程式碼

《Code Craft》 － The practice of writing excellence code
編程創藝，碁峯出版，蔡學鏞  譯

註：從圖書館借這本書來看，只細讀第一個part，也就是這邊筆記的ch1~ch6。後面的都是更進階、適合更專業的人，所以就只有大概瀏覽過去。

Ch 1 善於防守

• 必須設想最壞的狀況，不能一廂情願覺得「應該不會...」。
• 防禦性程式設計，是提前的防衛，而不是：檢查、測試、除錯。

防禦性程式設計技巧

• 使用好的風格和合理的設計 － 一定要先規劃
• 不要倉促地寫程式。欲速則不達。
• 不要相信任何人：始終保持懷疑，包括懷疑自己。
• 要清晰易於維護：過於艱澀複雜會讓之後難以維護，寧可多占用幾行把邏輯寫清楚。
• 不要讓別人做他們不該做的修補
• OOP封裝
• 盡量縮小變數的範圍
• 不要忽略compiler的警告
• 使用其他靜態分析工具
• 使用安全的資料結構
• 檢查所有的return
• 審慎處理記憶體和其他資源：該釋放就要釋放
• 盡可能推遲變數的宣告：使宣告更接近第一次使用到此變數的地方。
• 在宣告變數時就初始化。
• 審慎強制轉換型別
• Assert (斷言??)

Ch2 精心布局

誰會讀我的程式碼？除了別人，也可能是一段時間後的自己。

怎樣是好的樣式？

• 一致：風格在整個專案中保持一致
• 傳統
• 簡潔

關鍵概念:

• 選擇一個好的風格，並堅持下去。
• 遵循團隊或公司的風格。
• 若要修改一個現有或外來的程式碼，最好遵循它原有的風格。

Ch3 名正言順

關鍵概念: 若無法賦予一個東西有意義的名稱，是否也代表著你不夠理解它的功用，或它的功用定義不清楚？

• 描述性
• 技術上正確
• 符合該語言習慣
• 恰當：長度適中、格調（避免不嚴肅、亂寫的名字）
• 小心拼寫錯誤，避免使用拼寫過於相近、難以分辨的名稱

Ch4 不言自明  - 「自文件化」

第一次聽到「自文件化」這個觀念。意思是，相對於編寫外部說明文件以及程式碼中的註解，應該優先努力將程式碼自身編寫得容易閱讀。

• 好的樣式，例如if...else結構順序一致(例如固定先是正常情況，後是錯誤情況)
• 避免過多巢狀嵌套。不必拘泥於一定要 single entry, single exit
• 所有檔案、變數、函數都應賦予有意義的名稱。
• 保持函數精簡、作用明確。無須編寫複雜多功能的函數方法。
• 更加明確的型別描述: 例如const, unsigned

Ch5 編寫註解

關鍵概念：註解為何(目的)而非如何。

呼應「自文件化」的概念，程式碼是如何執行，應該直接閱讀程式碼，而非再寫註解。註解要寫的是這段程式為何存在。

「不要為差勁的程式碼寫文件－要重寫這些程式碼」 -- Kemighan & Plaugher

關鍵概念：

• 註解應活在現在，不要去描述已經改變的事、某個東西過去是做甚麼的。
• 所以，在修改程式碼時，一定要一併維護周圍的註解

Ch6 人非聖賢

關鍵概念：絕對不要忽視任何一種狀況、心存僥倖

錯誤報告機制:

• 返回值：函數成功與否的訊息包含在函數return值中
• 錯誤狀態變數：另外的變數，調用函數後需要查看這個變數，以確定函數執行成功與否。不建議使用全域變數做這樣的事。
• 例外
• 信號

處理錯誤應知道的資訊

• 錯誤來自何處
• 當時正要做什麼
• 為什麼會出錯
• 何時發生
• 嚴重性
• 如何修正

可能的反應

• 日誌：任何較大的專案都應該使用日誌工具。紀錄程式生命週期中值得注意的事件。
• 報告：程式應該只有在走投無路的情況下才向用戶報告錯誤。當然，如果這是用戶才可以解決的事，就立即向用戶報告吧。
• 恢復：停止，重新來過
• 傳遞：直接向上傳遞，或可重新解釋、封裝成為更有意義的訊息再傳遞。
• 忽略：不該這樣做！

關鍵概念：編寫程式時就要編寫錯誤處理的部分，不要拖延。拖到後面可能會忘，或是洞越來越大。