《Clean Code》Podcast 準備稿：什麼是乾淨程式碼・有意義的命名
書名： 無瑕的程式碼 Clean Code（A Handbook of Agile Software Craftsmanship） 作者： Robert C. Martin（Uncle Bob） 系列： Reading Uncle Bob（恩普拉氏） 公開標題建議： Reading Uncle Bob｜Clean Code．命名：程式碼是寫給人看的 (1/7) 涵蓋範圍： 導論 ＋ 第1章 無瑕的程式碼 ＋ 第2章 有意義的命名
背景速覽
這是 Reading Uncle Bob 系列、也是《Clean Code》的起手集。《Clean Code》(2008) 是與《重構》《Pragmatic Programmer》並列的軟體工匠三大必讀之一，作者 Uncle Bob 是 Agile 宣言共同起草人、SOLID 原則提出者。這集先講「為什麼程式碼整潔是專業素養的核心」，再從最基本、也最日常的功夫——命名——切入。
一句話重點
程式碼主要是寫給人看的（讀寫比約 10:1），所以「能跑」只是及格線，「好讀」才是專業；而好讀的第一道功夫，是讓每個名字都自己說清楚意圖，讓讀者不必猜、不必翻註解。
值得討論的重點
1. 讀寫比 10:1：可讀性就是生產力
Uncle Bob 的核心前提：我們花在「讀」程式碼的時間遠超過「寫」（約 10:1），而且寫新 code 時其實一直在讀舊 code。所以提升可讀性＝提升開發效率。他用一張「生產力 vs 時間」的曲線打掉一個迷思——「為了趕進度先犧牲品質」其實會讓你越來越慢，「加快的唯一方法是隨時保持整潔」。
2. 童子軍規則：讓營地比你來時更乾淨
不必大重構，每次打開檔案改東西時，順手把周邊清乾淨一點（改個爛名字、刪段死 code）。持續這樣，系統品質會隨時間上升而非腐敗。這是整本書最好落地、也最該推薦給聽眾的一條習慣。
3. 命名的幾條鐵律
- 名稱代表意圖：
dvscalculate_distance(speed)——名稱要回答「為何存在、做什麼、怎麼用」。要靠註解補充的名字，就是失敗的名字。 - 避免誤導：別用
accountList（除非真的是 List）、別用a1/a2/a3、別讓ProductInfo和ProductData並存。 - 可朗誦、可搜尋：
calc_avg_grd在 code review 唸不出來；單字母變數和魔術數字（7→MAX_CLASSES_PER_STUDENT）難搜尋。變數作用域越大，名字就該越長越具描述性。 - 問題領域 vs 解決方案領域：給工程師看的用
JobQueue，給業務看的用PremiumPolicy。
注意事項
⚠️ 別把 Uncle Bob 講成神諭。 《Clean Code》是 2008 年、以 Java 為背景的書，有些建議帶時代與語言色彩（如型別前綴、m_ 成員前綴的批評，是針對當年沒有現代 IDE 的習慣）。命名章的原則大多歷久彌新，但要提醒聽眾：原則背後的「為什麼」比規則本身重要——理解了「為了讓讀者不必猜」，你就知道何時可以變通。
⚠️ 命名「越大作用域越長、越小作用域越短」這條，反過來也成立——迴圈裡的 i、lambda 裡的 x 不需要長名字。別讓聽眾矯枉過正，把區域變數都取成落落長。
專家補充
💡 這集很適合先替整季「定錨一個誠實的立場」：《Clean Code》是經典，但近年也是被吵最兇的經典之一。 批評集中在後面幾章（函式長度教條、用多型取代 switch 的效能爭議——見 EP2、EP3），但命名與童子軍規則這一塊，幾乎沒有爭議、所有陣營都同意。先在第一集把「哪些是共識、哪些是 Uncle Bob 一家之言」這條線講清楚，整季會很穩。
💡 「程式碼是寫給人看的」這句其實出自更早的經典——Abelson & Sussman《SICP》前言：「程式必須寫得讓人讀，只是順便讓機器執行。」可以接到這條軟體思想史的源頭，顯得有縱深。
💡 命名難在哪？有句工程界老笑話：「電腦科學只有兩件難事——快取失效、命名、以及 off-by-one error。」命名之所以難，是因為它逼你真正想清楚這東西到底是什麼——命名困難往往是「設計還沒想清楚」的徵兆，這個洞見比任何命名規則都深。
討論問題
🎙️ 開場鉤子：「你上次接手一份 code，光是看懂變數在幹嘛就花了半小時——那份痛苦，其實就是別人沒做好今天要講的事。」
🎙️ 自問自答：「『能跑就好』到底錯在哪？」——用讀寫比 10:1 和那條生產力曲線回答：你省下的寫作時間，會在未來的閱讀與維護裡加倍還回去。
🎙️ 帶走的一題：「這禮拜，挑一個你每天都會打開的檔案，套用『童子軍規則』——只改一個爛名字就好。一個就好。」
更大範圍關聯
- 軟體工匠三經典：《Clean Code》＋《Refactoring》(Fowler)＋《The Pragmatic Programmer》。本系列／藍圖都把這三本列為旗艦，可互相引路（見 [軟體工程領域切分藍圖]）。
- 思想源頭：「程式為人而寫」接 SICP；命名與意圖接《Pragmatic Programmer》的「DRY」與「正交性」。
- 對立觀點預告：John Ousterhout《A Philosophy of Software Design》對「小函式／小類別」提出不同看法（深模組 vs 多淺模組），是這季最好的對照組，可在後段集數正式登場。
- Uncle Bob 系列：Reading Uncle Bob 共 6 本（Clean Code → Clean Architecture → Clean Coder → Clean Agile → Clean Craftsmanship → Functional Design），Clean Code 是入口。
錄製建議
- 建議時長：約 20 分鐘。配比：導論＋為何整潔約 7 分、命名約 12 分（命名是這集主菜，例子多、好講）。
- 討論策略：用「接手爛 code 的痛」開場最有共鳴；中段把命名規則用「好/壞對照」一條一條演（聽眾邊聽邊對照自己的 code）；結尾用童子軍規則給一個「明天就能做」的行動。整季的定調也在這集：經典要讀，但要帶腦讀。
- 這是系列起手，記得花 30 秒介紹 Reading Uncle Bob 是誰、這 6 本要幹嘛，建立系列感。