第 2 章 有意義的命名 15-28

2.1 介紹

　　文章列出取個好名字的幾條簡單規則。

2.2 名副其實

　　程式碼的模糊度：即上下文在程式碼中未被明確體現的程度。

2.3 避免誤導

　　程式設計師必須避免留下掩藏程式碼本意的錯誤線索。應當避免使用與本意相悖的詞。
　　提防使用不同之處較小的名稱。
　　以同樣的方式拼寫出同樣的概念才是資訊。拼寫前後不一致就是誤導。

2.4 做有意義的區分

　　要區分名稱，就要以讀者能鑑別不同之處的方式來區分。

2.5 使用讀得出來的名稱

2.6 使用可搜尋的名稱

　　長名稱勝於短名稱，搜得到的名稱勝於用自造變成代寫就的名稱。
　　竊以為單字母名稱僅用於短方法中的本地變數。名稱的長短應與其作用域大小相對應。若變數或常量可能在程式碼中多處使用，則應賦其以便於搜尋的名稱。

2.7 避免使用編碼

2.7.1 匈牙利語標記法

　　匈牙利語標記法：Hungarian Notation,HN。
　　現在不需要這種標記法了。

2.7.2 成員字首

　　也不必用 m_ 字首來表明成員變數。應當把類和函式做得足夠小，消除對成員字首的需要。

2.7.3 介面與實現

2.8 避免思維對映

　　不應當讓讀者在腦中把你的名稱翻譯為他們熟知的名稱。
　　聰明程式設計師和專業程式設計師之間的區別在於，專業程式設計師瞭解，明確是王道。專業程式設計師善用其能，編寫其他人能理解的程式碼。

2.9 類名

　　類名和物件名應該是名詞或名詞短語。類名不應當是動詞。

2.10 方法名

　　方法名應當是動詞或動詞短語。屬性訪問器、修改器和斷言應該根據其值命名，並以 Javabean 標準加上 get 、 set 和 is 字首。
　　過載構造器時，使用描述了引數的靜態工廠方法名。

2.11 別扮可愛

2.12 每個概念對應一個詞

　　給每個抽象概念選一個詞，並且一以貫之。

2.13 別用雙關語

　　避免將同一單詞用於不同目的。同一術語用於不同概念，基本就是雙關語了。如果遵循“一詞一語”規則，可能在好多個類裡面都會有 add 方法。只要這些 add 方法的引數列表和返回值在語義上等價，就一切順利。

2.14 使用解決方案領域名稱

　　記住，只有程式設計師才會讀你的程式碼。所以，儘管用那些電腦科學（ Computer Science,CS ）術語、演算法名、模式名、數學術語吧。依據問題所涉領域來命名可不算是聰明的做法，因為不該讓協作者老師跑來跑去問客戶每個名稱的含義，其實他們早該通過另一個名稱瞭解這個概念了。
　　程式設計師要做太多技術性工作。給這些事取個技術性的名稱，通常是最靠譜的做法。

2.15 使用源自所涉問題領域的名稱

　　如果不能用程式設計師熟悉的術語來給手頭的工作命名，就採用從所涉問題領域而來的名稱吧。至少，負責維護程式碼的程式設計師就能去請教領域專家了。
　　優秀的程式設計師和設計師，其工作之一就是分離解決方案領域和問題領域的概念。與所涉問題領域更為貼近的程式碼。應當採用源自問題領域的名稱。

2.16 新增有意義的語境

　　很少有名稱是能自我說明的-多數都不能。反之，你需要用良好命名的類、函式或名稱控制元件來放置名稱，給讀者提供語境。如果沒這麼做，給名稱新增字首就是最後一招了。
　　語境的增強也讓演算法能夠通過分解為更小的函式而變得更為乾淨利落。

2.17 不要新增沒用的語境

　　只要短命稱足夠清楚，就要比長命稱好。別給名稱新增不必要的語境。
　　對於 Address 類的例項來說， AccountAddress 和 customerAddress 都是不錯的名稱，不過用在類名上就不太好了。 Address 是個好類名。如果需要與 MAC 地址、埠地址和 Web 地址相區別，可以考慮使用 PostalAddress 、 MAC 和 UTL 。這樣的名稱更為精確，而精確正是嗎，命名的要點。

2.18 最後的話

　　取好名字最難的地方在於需要良好的描述技巧和共有的文化背景。與其說這是一種技術、商業或管理問題，還不如說是一種教學問題。