The beginning of wisdom is to call things by their proper name.

— Confucius（孔子）

核心概念#

名稱裡有什麼？在程式設計中，答案是「一切」。

我們為應用程式、子系統、模組、函式、變數取名——不斷創造新事物並賦予它們名稱。而這些名稱非常非常重要，因為它們揭示了你的意圖和信念。

我們認為事物應該根據它們在程式碼中扮演的角色來命名。這意味著每當你創建某個東西時，你需要停下來想：「我創建這個的動機是什麼？」

這是一個有力的問題，因為它把你從眼前的問題解決思維中拉出來，讓你看到更大的圖景。當你思考一個變數或函式的角色時，你在思考它有什麼特別之處、它能做什麼、它和什麼互動。

有科學研究支持名稱的深遠意義。大腦能非常快速地閱讀和理解文字——比許多其他活動更快。這意味著文字在我們嘗試理解事物時有某種優先權。這可以用 Stroop 效應來證明：說出文字的顏色比讀出文字本身困難得多。

命名範例#

• let user = authenticate(credentials) ——變數叫 user 因為它永遠是 user，但這沒有意義。改用 customer 或 buyer，這樣我們在編碼時會不斷被提醒這個人在做什麼
• deductPercent(double amount) ——方法名描述了做什麼而不是為什麼做，參數名 amount 含糊不清。改為 applyDiscount(Percentage discount) 更好——方法名表達意圖，參數使用自定義型別 Percentage 來記錄預期
• Fib.fib(n) ——在模組上下文中讀起來很冗餘。改用 Fib.of(0) 或 Fib.nth(20) 更自然

尊重文化#

大多數入門教材告訴你永遠不要用單字母變數如 i、j、k。作者認為這要看情況——取決於該程式語言或環境的文化：

• 在 C 語言中，i、j、k 傳統上是迴圈遞增變數，s 是字串——在該環境中這是被期待的
• 但在其他環境中使用這些慣例就同樣是錯的
• 有些語言社群偏好 camelCase，有些偏好 snake_case——尊重當地文化

一致性#

每個專案有自己的詞彙——行話（jargon）。「Order」在網路商店團隊和追蹤宗教譜系的團隊中意義完全不同。團隊中每個人都要知道這些詞的意思，並一致地使用它們。

鼓勵大量溝通：結對程式設計、頻繁換組可以讓行話自然傳播。也可以維護專案詞彙表（project glossary）。

重新命名更困難#

無論你前期投入多少心思，事物會改變。程式碼被重構，用法改變，含義微妙地被改動。如果你不在過程中持續更新名稱，你很快就會陷入比無意義名稱更糟糕的困境——誤導性的名稱。

正如 Topic 3（軟體的熵）所說，發現問題就立即修復。當你看到一個不再表達意圖、或具有誤導性的名稱，馬上修好它。

Tip 74 - Name Well; Rename When Needed（命名要好；需要時就重新命名）

如果因為某些原因你不能改名，你有更大的問題：ETC 違規（見 Topic 8，好設計的本質）。先修復那個問題，然後改名。讓重新命名變容易，並且經常做。

否則你就得面不改色地向新同事解釋：「getData 這個函式實際上是把資料寫入歸檔檔案。」

相關章節#

• Topic 3，軟體的熵
• Topic 40，重構
• Topic 45，需求之坑