一個「還算貼切」的名字，可能比明顯很爛的名字更危險——因為它會讓每個讀者反射式地做出錯誤假設，卻不自覺。命名的下限不是「別取爛名」，而是別留下會誤導的線索。
🧠 Why It's a Problem
- 誤導比模糊更貴：模糊的名字讓你停下來查；誤導的名字讓你充滿信心地讀錯，連查的念頭都不會有。
- 假型別的線索：除非變數真的是 List，否則別叫
accountList——改用accounts。資料結構關鍵字會讓人誤以為它是特定型別。 - 長得像、唸起來像的名字：
clientRecs與clientReps只差一字、input與inputValue可互換、wrap與rap口頭無法區分——這些都在製造混淆。至少讓名字有兩個字母的差異。 - 無資訊的命名：
a1, a2, … aN、temp、flag這類名字不提供任何線索；temp常常代表作者自己還沒真正理解問題。 - 太具體也是一種誤導：
void delete(Range selection)的selection暗示「被刪的一定是 UI 選取的文字」，但這方法能刪任何範圍——改叫range。
CAUTION
紅旗：模糊名稱（Vague Name）。 當一個變數或方法名廣泛到能指多種東西，它就沒提供有用資訊，而且更容易被誤用。getCount() 數什麼？x／y 是字元位置還是像素座標？換成 numActiveIndexlets、charIndex 這種對應到實際抽象的名字。
⚖️ Case Study
一個名字追了六個月
APoSD 作者在 Sprite 作業系統裡遇過最棘手的 bug——檔案偶爾莫名其妙丟資料、某個區塊突然全變 0。多位開發者讀過那段程式碼都沒發現，他自己花了六個月。
病因 — 一個名字身兼兩義
// block 有時裝「檔案內的邏輯區塊號」，有時裝「磁碟上的實體區塊號」
// 某處把持有邏輯區塊號的 block，誤用在需要實體區塊號的地方
function writeBlock(block, data) {
disk.write(block, data); // 期待實體區塊號，卻拿到邏輯區塊號 → 覆寫掉無關磁碟區塊
}block 對「實體區塊」與「邏輯區塊」都算貼切——正因如此，讀到它的人都反射式假設「這就是實體區塊號」，形成心智阻擋（mental block），沒人起疑。
解法 — 讓名字自己擋掉誤用
// 兩種概念、兩個名字：開發者一眼就知道 fileBlock 不能用在這裡
function writeBlock(diskBlock, data) {
disk.write(diskBlock, data);
}
// 呼叫端若手上是 fileBlock，型別對不上意圖，錯誤在寫的當下就顯眼用 fileBlock 與 diskBlock，這個 bug 幾乎不可能發生——開發者不會把 fileBlock 餵給需要 diskBlock 的地方。
IMPORTANT
教訓：多數人挑「第一個還算貼切」的名字就停手。block 不是爛名字，卻害人追了六個月。不要止步於「還算貼切」，多花幾分鐘找精確、無歧義、直覺的名字——這份投入很快回本。
🔑 Takeaways
- 誤導的名字比模糊的名字更危險：它讓人有信心地讀錯。
- 別用假型別線索（
accountList）、別用長得像／唸起來像的名字、別用temp／flag這種無資訊名。 - 太籠統與太具體都會誤導；名字要對應到程式碼實際實作的抽象。
- 「難以取一個精確又不冗長的名字」是設計問題的訊號，不只是命名問題——見 意圖揭露命名 與 一詞一概念。
No notes yet — jot your takeaways or Q&A here.