Coding，命名是個技術活

來吧

平常編碼少不了的事情就是給代碼命名，代碼中命名的重要性在項目前期不會有太大感覺，由於是邊作邊命名，代碼每天見，天然會加深記憶。但到了後期上線後半年一年後，再回過頭看的時候，我擦，這個變量是啥意思？這個方法不對呀，不是更新用戶狀態的嗎？ 接下來就是各類吐槽，誰寫的代碼，這麼爛，翻一下提交日誌，哦？我寫的，趕忙悄悄的改過來。

常常性咱們吐槽別人的代碼爛，那麼你是如何定義你認爲的爛代碼，它們爛在哪裏 ?

代碼究竟爛在哪裏

這個問題說的具體點，可能常常咱們在沒理清業務邏輯的狀況下去直接看別人的代碼，至關於經過代碼反推業務邏輯，別人的命名、編程思惟跟本身的習慣不一致，須要時間去消化理解他的邏輯和習慣，而後加上代碼排版亂七八糟，一堆if else，還摻雜着各類奇怪的命名，魔鬼數字，OMG，簡直不要太爽。以上綜合起來，大概就是你們眼中認爲的爛代碼吧。

簡要總結下：

• 自身緣由，業務並未徹底理解清楚，直接上手看代碼

這裏是建議先搞懂業務邏輯和相關的實體或數據庫表，最好是本身簡要畫出流程圖或時序圖輔助理解代碼，展開說的話比較多，後面有機會單獨寫一篇吧

• 代碼風格不規範

體如今各類接口、方法、變量的命名不規範，代碼格式排版混亂，過長方法，無註釋或不詳細等，註釋這塊最坑的不是沒有註釋，而是錯誤的註釋。本身腦補下畫面

• 代碼邏輯混亂

體如今代碼邏輯不清楚、冗餘代碼、廢棄方法、深層的嵌套等，怎麼優化，也值得單獨寫幾篇

能夠看到命名在裏面佔有一席之地，那麼如何作好代碼中的命名，且往下看。

好的命名，看這裏

先給出結論，一個好的命名最最最關鍵的一點，**見名知意，**見名知意，見名知意，重要的內容重複三遍，並加個底色。

不要怕長

我工做中碰到很多人有個命名習慣，我稱爲半命名方式，看個例子，定義一個業務需求的實體類，正常見名知意的命名是這樣的BusinessRequirement，可是，他們以爲這樣太長，他們會這樣
BusRequi、（各省一半）
BusinessReq（後面省一半）
BusinessXq（一半英文、一半拼音，洋不洋氣）
這樣的命名徹底不具備可讀性，還容易產生歧義。因此，不要怕長，能讓人和有道詞典讀懂是前提。

看個springboot中的命名
SpringApplicationJsonEnvironmentPostProcessor
長嗎？但確定能讀懂對吧。

可是有一類是能夠簡化的，就是行業內你們公認的術語簡稱，好比你想整個ip工具類，那麼你能夠這樣命名IpUtil，就不必整成這樣InternetProtocolUtil，由於Ip這個詞在業內你們都懂，就能夠簡寫。

準確

準確就是命名要符合當下的業務場景，好比我老早以前作的考試類項目中有個題目實體，同事採用的命名是Problem，顯然放這裏是不合適的，最後糾正爲Question。要作到準確，仍是比較考驗英文功底的。

具體

具體就是能正確表達變量或類所指向的代碼含義，例如咱們定義了一個表明軟件版本號的數組，可能會這樣定義

int[] array = new int[] {1,2,3,4,5};
複製代碼

數組卻是能看懂，可是單看這一行代碼並不能搞清楚幹什麼用，放在具體的代碼邏輯裏結合上下文代碼，倒也能推導出來數組中定義的具體是什麼，可是增長的閱讀代碼的難度，好一點的固然是下面這樣

int[] versionNumberArray = new int[] {1,2,3,4,5};
複製代碼

說清楚具體含義，表示的是什麼數組，而不是隻抽象的表達個數組的概念。

額外補充一點

我見過一個項目從代碼到數據庫總體命名都是拼音簡寫形式，說實話拼音簡寫對業務不熟悉人來講很難識別，並且時間一長徹底是懵逼的，徹底得靠猜。

拿上面的業務需求來講拼音整出來Ywxq，拼音組合能夠有不少種解讀。項目得以持續維護的關鍵是他們有詳細的字典說明文檔，實際上就是上篇文章說的**公司或團隊有一套本身的標準就行**。

可是可想而知仍然很痛苦，除非是個別領域內的專業詞彙，英文很難表達，能夠嘗試拼音解決，其餘狀況仍是儘可能用英文命名。

總結

好的命名就是作到見名知意，具體遵循如下幾點：

一、不要怕長，專業術語行業內有簡稱，可用簡稱
二、用詞準確
三、表達具體
四、儘可能使用英文
五、上面沒提到的一點，公司有規範，優先符合公司規範

未入行以前，不少人老是好奇，英文基礎對編碼到底有沒有影響，到底有多大，這裏就能夠看到，是有影響的，起碼命名的時候有障礙，須要藉助有道詞典或 code if 這樣的工具。

並且越日後英語的重要性就越發明顯，好比你能夠直接讀一手英文資料、文獻等。

最後

寫完了老感受爛代碼這個詞用的很很差，奈何詞窮，先這麼着吧。