在公司裡，我有個不怎麼常用的綽號，叫“算命先生”——幫別人起名字的，準確說，幫別人的程式碼起名字，包括專案名，目錄名，類名，屬性名，方法名，變數名等。事實上，我也確確實實幫過別人起名字，起名字總歸有些套路，要避開一些坑，一個好的名字就是一個成功的開始，反之可能後面會帶來很多困擾。我跟同事說，好的名字讓你行走江湖更容易，你看“葉孤城”、“西門吹雪”、“東方不敗”這些名字一聽就知道是絕世高手，但你試著叫“王霸天”、“李二狗”、“牛春花”，不是活不過兩集就是連上鏡的機會都沒有。 下面分享一些個人的經驗及看法，所有的觀點都並非絕對，當你看完整篇文章後肯定也深以為然，我所提出的這些套路也是為了這麼個中心服務的： 使得程式碼更有條理和可讀性。

1，用英文，別用中文，別用拼音，更加別用拼音縮寫

這應該是老生常談了。 C#/Java語言挺神奇，可以用中文做識別符號，比如你建立一個類，叫“貨物訂單”，完全沒問題，但有人嘗試過之後就很快放棄了，因為可讀性實在太差了，另外在做程式碼搜尋的時候，輸入中文字身就比英文要慢，英文還方便用正則等去匹配，中文在這方面操作起來就比較困難，如果你還想把程式碼移植到別的語言去，就更加不能用中文了。 拼音也別用，因為拼音你不念出來的話你往往不知道它想表達什麼意思，漢語拼音中還有聲調，而程式碼中又表示不了，有時候真能讓閱讀者一臉懵逼。 那拼音縮寫就更加不用說了，我維護過一些老古董程式碼就全是拼音縮寫，噁心+崩潰。

好	不好	不好	垃圾
GoodsOrder	商品訂單	ShangPinDingDan	Spdd
InventoryCheck	庫存檔點	KuCunPanDian	kcpd
InvoiceManagement	發運單管理	FaYunDanGuanLi	fydgl
RouteConfiguration	路由配置	LuYouPeiZhi	lypz

2，不要拼寫錯誤

這不是廢話麼？但也不知道是由於不小心還是英文水平太差，我遇到的程式碼中的拼寫錯誤實在太多太多了，更有甚者把公司的名稱都寫錯的。如果你哪天用微軟的程式碼，發現名稱空間是：Micorsoft.Extensions.Logging，你會有什麼感受？ 寫程式碼和做別的事情一樣，也需要用心，遇到不確定的東西時，查一下，問一下，如發現自己之前的問題，要及時修正。 隨便列舉一些拼寫錯誤(跟技術無關，純粹看英語水平和仔細程度)

錯誤	正確	描述
lable	label	字母前後寫錯是常發生的事情
catched	caught	catch的過去分詞為不規則
loging	logging	注意新增-ing的特例
IsEnable	IsEnabled	Enabled才是形容詞，才能用系動詞
登陸	登入	你以為中文的錯別字就少了？
SingleBox	PackingList	本公司的梗，“發票箱單”，某同事翻譯成了Single(單)Box(箱)，奇葩

3，用名詞充當類名

類，通常表示一個數據實體，或者一系列資料與方法的封裝，大多時候是應當使用名詞的。下面是一些例子：

名稱	不太好	不錯
登入資訊	Login(這是動詞唉)	LoginReq(Req表示Request，一看就知道這是個登入請求) 或LoginUi，字尾Ui表示UI層使用的類。
出庫訂單	Order(太普遍了，且order是SQL的關鍵字，容易帶來一些不便)	OutBoundOrder
全域性變數	Global(這是形容詞)	GlobalData，GlobalAppConfig等
匯流排請求類	BusRequest(這是動詞)	BusRequester(請求者，湊合，但仍不太好) BusReqManager(這個名字明顯更好)

4，不要使用太普遍的名詞充當類名

 如Configuration，這個詞表示配置，你打算建立這麼一個類表示系統的配置資訊，並提供相應方法。但你要注意了，一個較大的系統裡通常有很多很多的配置，比如程式的全域性配置，入庫規則配置，出庫規則配置，外部介面訪問配置，日誌配置……如果你全都叫Configuration，你很可能三天兩頭被自己搞懵。那怎麼辦？寫具體點不就行了麼？

不好	好一點	說明
Configuration	GlobalApplicationConfiguration InBoundConfiguration ExteralApiConfiguration LoggingConfiguration	起碼更具體了
Param (某個外部API的引數)	GenericExternalApiParam	識別符號命名沒必要再從技術上描述它是什麼東西，正如你不需要寫完“int i=1”後加個註釋“定義整型變數i並賦值1”，要使得名字符合業務邏輯

當然，也有例外的情況，比如我的專案中通常有個類叫“Fmt”，非常簡單，其實就是Format的簡寫，這個類不涉及到具體的業務邏輯，只是用來對時間日期和數值進行一些格式化操作，所以可以起個這麼簡的名字。

5，適當的簡寫與約定俗成的縮寫

 上面起的名字你是不是覺得太長了？那可不可以縮寫一些？那是肯定的，程式碼中，我們存在著很多約定俗成的“單詞”，舉個最簡單的例子：ID，ID是Identity的簡寫，為什麼我們現在都知道？因為已經“約定俗成”了，這種例子還很多，我隨便舉一些：

原本	簡寫
participant	ptcp
application	app
description	desc
abbreviation	abbr
configuration	config或cfg
Machintosh	Mac

縮寫的規則通常是取前面幾個字母，但也有例外的，如前面提到的participant，如果縮寫為part的話，由於part是另外一個單詞，容易引起誤會，所以就取participant中的幾個與發音相關的子音字母來組成簡寫，所以configuration也可以簡寫為cfg，關鍵是要大家都認可。

6，約定俗成的縮寫

 英文中的縮寫實在太多了，如果沒有這些縮寫，用英語就簡直無法交流，我並不誇張，隨便寫幾個縮寫的例子：

英文縮寫	英文全稱	中文
NASA	National Aeronautics and Space Administration	美國國家航空和宇宙航行局
BASIC	Beginner's All-purpose Symbolic Instruction Code	初學者通用符號指令程式碼
EPROM	Electrically Programmable Read-Only-Memory	電可程式設計序只讀儲存器
JSON	JavaScript Object Notation	JavaScript物件表示式
ASN	Advanced Shipment Notice	預到貨通知單
DN	Delivery Number	運單號

現在你有問題了：“你前面剛說拼音縮寫‘垃圾’，為什麼這裡又允許英文縮寫？”Good question，我這樣說吧：關鍵點在於約定俗成，大家認可，英文中的縮寫詞經常能自己成為一個單詞，如ROM，我們都直接念它“[rɔm]”，而不是“R-O-M”，大家都已經認可了“ROM”這個單詞了，這就可以了。文章一開始我也說了，所有這些，都是為了這個中心服務的：使得程式碼更有條理和可讀性！所以我提出的建議也只是建議，不是鐵律。 這麼說的話，我們是不是拼音縮寫在某些時候也能用一下？——沒錯，我們公司經常就用Shwgq來表示“上海外高橋”，一來“上海外高橋”是專有名詞，只能寫拼音，二來公司同事都已經認可了，於是就可以愉快地使用了，但我又要說回來，這個是個特例，千萬不要濫用。

7，駝峰命名法

 先問這麼一個問題：UserID好，還是UserId好？ 也許你有你的看法，而我的看法很明確：UserId好，因為它很好地區分出了ID這個“單詞”，前面說了ID是Identity的簡寫，但認可的人多了之後，ID本身就成為了一個單詞，根據駝峰命名法的規則，單詞首字母大寫，其餘小寫，因此應當寫UserId，可能一開始感覺有點不習慣，但後面很快就能適應。 另外還有一個問題：UserName好，還是Username好？ 按規則應該是Username，因為這本身就是一個單詞，但由於歷史原因，在我的專案裡面，一律寫成UserName，以前寫錯了，慣性太大，改不了，就當是User和Name兩個單詞拼成的吧——看吧，兵無常勢水無常形，要靈活應變。 另外還要注意一點，用駝峰命名法的時候，避免連續出現大寫字母，否則很影響程式碼可讀性。

8，適當使用字尾區分

 有時候實在不知道怎麼起名字，如登入，叫“Login”，這個也許表示客戶端向伺服器提交的登入請求，但也能表示伺服器處理好登入請求後返回給客戶端的資訊， 怎麼辦？ 我的辦法是加上字尾作區分：

登入	登入請求	登入響應
Login	LoginReq	LoginResp

這樣就非常清晰了，Req即Request，Resp即Response，這種方法還能把Login這個動詞變作一個名詞，太好用了。 再比如，員工資訊，叫EmployeeInfo，它可以是來自客戶端的提交的資訊，根據系統的分成架構，這個Model需要從UI層傳遞到業務邏輯層，但這兩個層的EmployeeInfo類是有差別的，難道都要叫EmployeeInfo，只用名稱空間來區分嗎？我的“套路”一般如下：

員工資訊	UI層的員工資訊	業務邏輯層的員工資訊
EmployeeInfo	EmployeeInfoUi	EmployeeInfoBl 或 EmployeeInfo

UI層加上Ui字尾(根據前面提到的規則，i小寫)，業務邏輯層可以加上Bl，也可以不加，因為UI層加了，就表示可以區分開來了。

9，用謂賓結構來命名方法

 方法表示某個執行動作，通常都是謂賓結構，為什麼把主語省掉了？因為主語100%是呼叫者，根本不用問。這是一些例子：

方法	好
報關單作廢	CancelDeclaration
檢驗是否存在	CheckIfExisting
出庫確認	ConfirmOrder
刪除核放單	DeleteGatebill

沒太多好說的，在動詞的選擇方面，有以下這些常用動詞：

動詞	英文
建立	Create
增加	Add(注意跟“建立”語義上的差異)
更新/編輯	Update/Edit
刪除/移除	Delete/Remove
清空	Clear/RemoveAll
獲取/設定	Get/Set
傳送/接受	Send/Receive
檢查是否XXX	CheckIf
生成	Generate
計算	Calculate
上傳/下載	Upload/Download
萬能動詞	Do/Make

還有很多，我不列了，否則就真的變成上英語課了，英語和漢語一樣，同義詞很多，但語義上常常會有些微小的差異，比如建立和增加，建立一個新使用者，這是一個從無到有的過程，所以通常用Create，而將這個建立好的使用者加到開發部門中去，則是Add的概念，開發部門本來就存在的，只是多了一個人，大家去體會體會。我們在選動詞的時候通常會選比較符合英文文法的詞，而不能太過於“技術”，如選擇Create而不是SQL的Insert，因為Insert是個資料庫技術中的概念，而不是業務邏輯上的概念，再如選擇Send而不是Post，也是一樣道理，但這個並不絕對，假如你開發的是一個網路訪問的基礎庫，那麼你完全可以用Post啊，因為這個情形下，Post本身就更能描述業務邏輯。 實在不知道怎麼選動詞的話可以考慮下Do和Make這兩個萬能動詞，DoXxx，可以表示幹任何事情，而Make一樣很萬能，Trump大帝競選美國總統的時候口號不是“Make American Great Again”麼？使或讓的意思，放在很多場合都適用，再比如Make money，“賺錢”的意思。

10，複數與列表

 有次我複查程式碼，看到一個“訂單”中的“訂單明細”是這麼命名的：OrderLineCounts。莫名其妙，這根本不通啊。 用“Line”表示明細是我們公司的約定俗成，一個訂單主檔中帶若干訂單明細，我說用來表示這種明細列表通常有兩種方法，一種是用複數，另一種加個List字尾：

不通	通	通
OrderLineCounts	OrderLines	OrderLineList

這裡還要注意一下： 1，不是所有名詞都有複數形式，英語中有些詞不可數對不？所以加個List字尾可能更通用一些 2，不是所有可數名詞都可以直接加s變成複數形式，如Data，其複數形式應該是Datum，不要寫Datas 3，有些單詞單複數同形，如Goods，商品，複數也是Goods，不要寫作Goodses

最後

 講一個東西，叫“破窗效應”(Broken Window Theory)，我是許多年前在《程式設計師修煉之道》這本書上看到的(這本書強烈推薦一下)，這個道理很簡單，就是說如果你一開始對系統中出現的破敗視而不見的話，更多的破敗就會出現，直到事態不可挽回。你對程式碼的命名不認真，馬馬虎虎，導致同事看不懂，同事誤會了你的意思，跟著你亂命名，你再次接手這程式碼的時候，已經凌亂不堪，你感覺已經很難維護，於是更加得過且過，直到程式沒人再敢去碰。 “宇宙的熵在升高，有序度在降低，像平衡鵬那無邊無際的黑翅膀，向存在的一切壓下來，壓下來。可是低熵體不一樣，低熵體的熵還在降低，有序度還在上升，像漆黑海面上升起的磷火，這就是意義，最高層的意義，比樂趣的意義層次要高。”——《三體：死神永生》