如何命名：編程中最難的事
喬治·奧威爾的命名規范
如何命名？簡言之，根據語意來選擇詞匯，別無它法……然而，有時我們會不知用什么詞匯更合適。
當你想到某個抽象的東西，你更傾向于***想到的詞語，除非你故意不這樣，這些詞也會搶著出現，直到模糊或改變你的想法。當你想到一個具體的對象，你覺得詞窮，然后你想描述的已經看到了，然后你繼續尋找更適合它的詞。
六條原則
以下是喬治給出的命名六原則：
1. 絕不要用隱喻，明喻或者是其他書本上看到的語言描述方式
2. 絕不要用太長的詞匯，如果一個短的詞匯已能說明問題
3. 如果可能縮短用語，就盡量縮短
4. 絕不要用被動語態的詞，如果能用主動語態的詞
5. 絕不要使用外來詞匯，學術術語，如果你能想到意思相近的日常用語
6. 打破上述任何規則，相比更加直接明了的說話方式
這些規則聽起來很條文，確實也是如此。但對于那些習慣了流行的寫作風格的人來說，這幾點卻尤為重要。下面具體來解釋這六條原則。
1、絕不要用隱喻，明喻：以防過度使用慣用的設計模式，只是因為在代碼中看慣了。如：
AbstractConfigurationFactory
2、只要能短就不要用長詞：如果一個短的詞匯已能說明問題，則盡量使用簡潔的變量命名，僅在有更好的理由的前提下才使用長的命名。如：
company_person_collection
vs
Staff
3、如果可能縮短用語，就盡量縮短：避免添加一些毫無意義的詞匯到命名中。如：
AbstractObjectFormatterProxy
……
org.springframework.web.servlet.support.
AbstractAnnotationConfigDispatcher
ServletInitializer
這就像是同類療法。你所應該做的就是簡化，直到什么都沒有。 ”By Kevlin Henney。
4、盡量用主動語態的詞：能用主動就絕不用被動語態的詞，便于用戶理解，同時也遵守標識符的語法規則。
如：
class PlanEvents
vs
class EventPlanner，或者甚至是 class Scheduler。
5、盡量用日常用語，避免使用外來詞匯或學術術語，不要讓來自某個庫的專用術語污染你的領域模型，同時也提防那些從其他語言導進外來”命名的庫。
如：ShipmentMonad
6、打破上述任何規則，如果你有更簡單明了的表述方式。當然，如果你的代碼正刊登在眾多知名的網站，如 The Daily WTF，你可以忽略我說的話。（The Daily WTF，美國著名丑陋代碼開發、災難開發案例網站。）
注：許多取決于上下文;
當然，發布庫代碼和維護私有程序代碼是不一樣的。
聽到這，是不是感覺寫代碼和寫散文一樣困難？
作家們對于編程的啟發
關于偶編程——斯蒂芬·金（Stephen King）
“關著門寫，開著門重寫。”
關于硬件開發——安妮·賴斯（Anne Rice）
“我發覺更大的顯示屏更易讓人專注。”
關于用戶角色——厄內斯特·海明威（Ernest Hemingway）
“當寫小說的時候，作家應該創造鮮活的人物；人物不是角色。角色是在漫畫里的。”
關于企業架構 ——威廉·薩默塞特·毛姆
“寫小說有三條規則，不幸的是，沒人知道是什么。”
關于代碼效率——尼爾·蓋曼（Neil Gaiman）
“寫作。一個字接著一個字。找到正確的詞匯，運用它。完成你正在寫的東西。無論如何都請完成，一定要完成。”
關于代碼審查——尼爾·蓋曼
“把它放在一邊。仔細閱讀，假裝之前從未閱讀過。展示給你的朋友，并聽取他們的意見和觀點。”
關于反饋——尼爾·蓋曼
“當人們告訴你哪是可能出錯了，或者沒有正常的運行，他們幾乎總是對的。”
“當他們告訴你他們認為什么是錯的，并如何解決它，他們幾乎總是錯的。”
關于重構——尼爾·蓋曼
“處理它。請銘記，它能達到***之前，遲早你都要放下并且繼續前進，開始寫后面的東西。***就是像追逐地平線。 不斷繼續前進。”
關于代碼里的幽默 ——尼爾·蓋曼
"Laugh at your own jokes." “笑你自己的笑話。”
關于開源——尼爾·蓋曼
"The main rule of writing is that if you do it with enough assurance and confidence, you’re allowed to do whatever you like."
“寫作的主要規則是，如果你有足夠的擔當和自信來做這件事情，你將被允許做任何你想做的事。”
來自作家們建議的總結
來自作家的建議是有用的，不僅僅是對于編程中的命名。作家已經存在幾個世紀、而編程僅僅有幾十年的歷史。此外，如果你真正理解了，他們的建議其實是更好的寫作和更多快樂。
