《Clean Code》Podcast 準備稿：編排・物件與資料結構・錯誤處理
書名： 無瑕的程式碼 Clean Code（A Handbook of Agile Software Craftsmanship） 作者： Robert C. Martin（Uncle Bob） 系列： Reading Uncle Bob（恩普拉氏） 公開標題建議： Reading Uncle Bob｜Clean Code．編排、物件與錯誤處理：別讓錯誤淹沒主邏輯 (3/7) 涵蓋範圍： 第5章 編排 ＋ 第6章 物件及資料結構 ＋ 第7章 錯誤處理
背景速覽
這集把三章「中段功夫」收在一起：編排（程式碼的視覺溝通）、物件 vs 資料結構（一個常被忽略卻很深的設計分野）、錯誤處理（怎麼讓 error handling 不污染主邏輯）。三章都偏「結構與設計」，比命名／函式更進一階。
一句話重點
程式碼的排版是一種溝通（像報紙一樣由上而下、相關的靠近）；物件與資料結構是兩種對立的設計哲學（該選哪個要看你預期「未來加什麼」）；而錯誤處理的關鍵是把它隔離成獨立的關注點，別讓 try-catch 和 null 檢查淹沒了業務邏輯。
值得討論的重點
1.（編排）程式碼像報紙：垂直敘事、相關靠近
- 垂直：用空白行區隔「思緒段落」；關係緊密的 code 要靠近；變數宣告緊貼使用處；函式「由上而下」排（高階在上、細節在下，像先讀大綱再讀細節）。
- 水平：別讓人拉水平捲軸（80–120 字元）；運算子兩側留白以表達優先級。
- 團隊一致性 > 個人喜好：這是最重要的一條——縮排、括號位置全隊統一，讀者才能信任格式的意義。
2.（物件 vs 資料結構）一個深刻的反對稱
這章常被低估，但很關鍵：
- 物件：隱藏資料、暴露行為（封裝）。好處：加新「型別」不用改現有函式（對行為封閉）；壞處：加新「行為」要改所有類別。
- 資料結構（過程式）：暴露資料、行為寫在外部函式。好處：加新「行為」不用改資料結構；壞處：加新「型別」要改所有函式。
- 結論：不是「萬物皆物件」——看你未來預期加什麼（常加型別→OOP；常加行為→資料結構＋函式）。DTO 是純資料結構，別塞業務邏輯進去變成「混合體」。
3.（錯誤處理）把錯誤隔離成獨立關注點
- 用例外取代錯誤碼（避免
if (err != OK)巢狀）；先寫 try-catch-finally（把 try 當交易）。 - 別回傳 null、別傳遞 null——回傳空集合或用「特例模式（Special Case Pattern）」物件，消滅滿地的
if (x != null)。 - 例外要帶足夠的上下文；包裝第三方例外成對呼叫者有意義的型別。
注意事項
⚠️ 編排章「函式由上而下」的排列，現代 IDE 時代弱化了。 有「跳到定義」之後，函式物理順序沒那麼關鍵——但「相關的靠近、用空白分段」仍然成立。提醒聽眾抓重點（可讀的視覺結構），別拘泥於 2008 年的排版細節。
⚠️ 「別用 checked exceptions」是針對 Java 的特定主張、且有爭議。 Uncle Bob 認為 checked exception 違反 OCP（底層改簽章、上層全要改）。但這在 Java 社群一直有兩派；而且其他語言（如 Go 的 error 回傳值、Rust 的 Result）根本走相反路線。要框成「這是 Java 脈絡下的觀點」，別當成跨語言真理。
⚠️ 「別回傳 null」很對，但要補現代做法：很多語言已有更好的工具（Optional/Maybe、Result 型別、non-nullable 型別系統如 Kotlin/Swift）。Uncle Bob 的「特例模式」是 2008 年的解法之一，今天有更語言原生的選擇。
專家補充
💡 物件 vs 資料結構的反對稱，其實就是著名的 「Expression Problem（表達問題）」——OOP 容易加型別、難加操作；FP（資料＋函式）容易加操作、難加型別。Uncle Bob 在 2008 年用樸素語言點出了這個深刻問題，值得替聽眾接到這個更大的理論框架，顯出縱深。
💡 「別回傳 null」可以連到 Tony Hoare 那句名言：他稱發明 null 為「我十億美元的錯誤（billion-dollar mistake）」。這個典故很適合在節目裡講，既有梗又點題。
💡 錯誤處理的「特例模式」是 Martin Fowler《PoEAA》裡的正式 pattern（Special Case / Null Object）——本系列藍圖裡 PoEAA 是旗艦大書，可預告：很多 Clean Code 的招式，在 Fowler 那裡有更完整的型錄。
討論問題
🎙️ 開場鉤子：「同一段邏輯，排版好和排版爛，閱讀速度可以差好幾倍——但我們常覺得『那只是格式』。Uncle Bob 說：排版是你身為專業開發者最主要的溝通工具。」
🎙️ 自問自答：「『萬物皆物件』是不是一種迷信？」——用物件 vs 資料結構的反對稱回答：成熟的工程師會看「未來要加什麼」來選，而不是無腦包成 class。
🎙️ 帶走的一題：「檢查你最近寫的函式：有沒有滿地的 if (x != null)？想想能不能用空集合、Optional 或特例物件，讓呼叫端不必一直防禦 null。」
更大範圍關聯
- PoEAA（Fowler）：特例模式／Null Object 的正式出處；本系列旗艦大書，可互引。
- Expression Problem：物件 vs 資料結構接到 FP/OOP 的根本權衡，也預告系列終卷《Functional Design》。
- 跨語言錯誤處理：Java 例外 vs Go error 值 vs Rust Result——很好的【主題】跨書/跨語言題目。
- null 的歷史：Tony Hoare「十億美元的錯誤」，接現代型別系統（Kotlin/Swift non-null）。
錄製建議
- 建議時長：約 20 分鐘。三章各約 6–7 分；物件 vs 資料結構是最有「深度感」的一段，可多給一點。
- 討論策略：三章看似零散，用一條線串起來——「從視覺（編排）→ 結構（物件/資料）→ 健壯（錯誤處理），都是在管理『讀者的認知負擔』」。編排用「排版是溝通」破題，物件章用「萬物皆物件是不是迷信」製造思辨，錯誤處理用「null 十億美元錯誤」收尾。
- 單人主講時，物件 vs 資料結構的「加型別 vs 加行為」對稱，建議用一個具體例子（如 Person 類別）邊講邊推，比抽象敘述好懂。