命名不只是給變數一個代號，它是可讀性的第一道防線。一個好名字能回答三個問題：這東西為什麼存在？它做什麼？該怎麼用？當名字本身就把意圖說清楚，讀者就不必再靠註解或猜測去補完——因為程式碼主要是寫給「人」看的，其次才是給機器執行。
🧠 Core Ideas
- 讓名稱代表意圖（Intention-Revealing）。名字如果需要一行註解補充說明，就代表它已經失敗。
d什麼都沒說，elapsedTimeInDays一眼就懂；改名的成本極低，換來的可讀性回報卻很高。 - 避免誤導（Disinformation）。別留下掩蓋本意的錯誤線索：除非變數真的是 List，否則別叫
accountList（改用accounts）；避免hp、aix這類易混淆的專有縮寫；也別讓ProductInfo與ProductData這種難以區分的名字並存。 - 名稱要能唸、能搜尋。寫程式是社交活動，唸不出來的名字在 Code Review 時無從討論；單字母變數與魔術數字在大型專案裡幾乎無法精確定位——用
MAX_CLASSES_PER_STUDENT = 7取代裸露的7。 - 長度與作用域成正比。變數的有效範圍越大，名字就該越長越具描述性；反之短作用域的迴圈計數器用
i反而清楚。 - 一個概念只用一個詞。別讓
controller、manager、driver在同一專案裡混指類似概念，讀者會困惑它們到底差在哪；選定一個詞，貫徹到底。 - 選對讀者的術語。給工程師看的用 Solution Domain（
JobQueue、OrderObserver），給業務邏輯用 Problem Domain（PremiumPolicy、ClaimVoucher），讓讀者不必在腦中把你的變數翻譯成他熟悉的概念。
TIP
現代 IDE 會顯示型別、用顏色區分成員變數，所以匈牙利式的型別編碼（str、i_）、成員前綴 m_、介面前綴 I 大多已是純視覺雜訊。把裝飾拿掉，讓名字專注在「它是什麼」而非「它是什麼型別」。
⚖️ 為什麼壞名字的代價會被放大
命名看似小事，但因為程式碼被讀的次數遠多於被寫，任何讓名字難懂的捷徑，都會在後續每一次閱讀時重複收費。
三種常見的命名陷阱
-
無意義的序列命名。
a1, a2, ... aN這種數列命名完全不提供任何線索，讀者只能回頭去讀實作才能猜出用途——等於把命名該做的工作推給了每一位讀者。 -
贅字與重複上下文。在
Car類別裡把方法叫getCarSpeed，car是多餘的——讀者已經知道這是 Car 的方法。移除贅字後getSpeed反而更清楚。 -
相似到無法區分的名字。當兩個名字語意幾乎沒差（
ProductInfovsProductData），讀者無法從名字判斷該用哪一個，只好回去讀原始碼——命名的價值就此歸零。
🖼️ 命名是降低認知負擔的工程手段
Uncle Bob 把命名放在《Clean Code》全書第二章、緊接在「什麼是整潔程式碼」之後，不是偶然：在他的體系裡，好命名是「意圖自明」最直接的實現。書中特別區分兩種術語領域——面向工程師的 Solution Domain 使用演算法與設計模式的詞彙（UserBuffer、OrderObserver），面向領域專家的 Problem Domain 使用業務語言（EscrowLedger、ClaimVoucher）。選對領域，等於確保技術實現與商業需求對齊，讓不同背景的讀者都能無痛理解。
命名還牽動詞性的一致：類別與物件用名詞或名詞片語，方法用動詞或動詞片語。這些規則的共同目的只有一個——把讀者「翻譯」程式碼的認知成本降到最低。當每個名字都精準對應到讀者腦中的既有概念，程式碼就能像文章一樣被順讀，而不是像密碼一樣被解碼。
IMPORTANT
好命名的最終判準不是「漂亮」，而是「讀的人不需要猜」。當你發現自己想寫註解解釋一個變數是什麼，先問：能不能改個名字讓註解變得多餘？多數時候答案是可以——這也是為什麼《Clean Code》說註解往往是一種失敗的補償。
🔑 Takeaways
- 好名字回答三個問題：為什麼存在、做什麼、怎麼用；需要註解補充的名字就是失敗的名字。
- 避免誤導與贅字：別用
accountList這種假型別、別在Car裡重複car前綴。 - 作用域越大名字越長；用具名常數取代魔術數字，讓程式碼可搜尋。
- 一個概念只用一個詞，並依讀者選 Solution / Problem Domain 的術語。
- 延伸：命名整潔之後，下一步是讓函式短小、只做一件事，見 函式：短小、只做一件事。
No notes yet — jot your takeaways or Q&A here.