作者親身經歷的最棘手 bug，根因就是一個糟糕的變數名。

故事：Sprite 作業系統#

1980 年代末、1990 年代初，作者與研究生創造了分散式作業系統 Sprite。

某天他們發現：偶爾有檔案會丟失資料——某個資料區塊突然全變成 0，雖然該檔案並未被使用者修改。

• 發生頻率低 → 極難追蹤
• 幾名研究生試圖找出 bug，全都放棄

作者對「未解 bug」抱持「無法忍受的個人侮辱」心態，於是親自接手——花了六個月才找到並修好。

問題的本質#

bug 其實很簡單（多數 bug 找到後都是如此）：

• 檔案系統程式碼中有個叫 block 的變數
• 它在不同情境下被用作兩種完全不同的東西：
  • physical block number（磁碟上的實體區塊號）
  • logical block number（檔案內的邏輯區塊號）
• 某處的 block 持有的是邏輯區塊號，卻不小心被用在需要實體區塊號的位置
• → 一個無關的磁碟區塊被覆寫為 0

為什麼追了六個月#

找 bug 過程中，包含作者自己在內的多位開發者都讀過那段有問題的程式碼，沒人發現。

看到 block 被用作實體區塊號時，大家反射式地假設它就是實體區塊號。

最後是透過大量檢測（instrumentation），鎖定哪個 statement 造成資料毀損後，才終於有辦法擺脫名稱造成的「心智阻擋」（mental block），追溯它的值是怎麼來的。

改名就能避免#

如果用 fileBlock 與 diskBlock 兩個不同的名字 → 這個 bug 幾乎不會發生。

開發者一眼就會知道 fileBlock 不能用在那種情境。

教訓#

多數開發者不在命名上花時間。

他們挑「第一個還算貼切」的名字。block 對「實體區塊」與「邏輯區塊」確實還算貼切——絕不是糟到爆的名字。

但就是這樣一個還可以的名字，害他們花了大量時間追一個微妙 bug。

不要止步於「還算貼切」，多花一點時間找精確、無歧義、直覺的好名字。這份投入會很快回本。