來吧
日常編碼少不了的事情就是給代碼命名，代碼中命名的重要性在項目前期不會有太大感受，因爲是邊做邊命名，代碼天天見，自然會加深記憶。但到了後期上線後半年一年後，再回過頭看的時候，我擦，這個變量是啥意思？這個方法不對呀，不是更新用戶狀態的嗎？ 接下來就是各種吐槽，誰寫的代碼，這麼爛，翻一下提交日誌，哦？我寫的，趕緊悄悄的改過來。
經常性我們吐槽別人的代碼爛，那麼你是如何定義你認爲的爛代碼，它們爛在哪裏 ?
代碼究竟爛在哪裏
這個問題說的具體點，可能經常我們在沒理清業務邏輯的情況下去直接看別人的代碼，相當於通過代碼反推業務邏輯，別人的命名、編程思維跟自己的習慣不一致，需要時間去消化理解他的邏輯和習慣，然後加上代碼排版亂七八糟，一堆 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，拼音組合可以有很多種解讀。項目得以持續維護的關鍵是他們有詳細的字典說明文檔，實際上就是上篇文章說的公司或團隊有一套自己的標準就行。
但是可想而知仍然很痛苦，除非是個別領域內的專業詞彙，英文很難表達，可以嘗試拼音解決，其他情況還是儘量用英文命名。
總結
好的命名就是做到見名知意，具體遵循以下幾點：
1、不要怕長，專業術語行業內有簡稱，可用簡稱
2、用詞準確
3、表達具體
4、儘量使用英文
5、上面沒提到的一點，公司有規範，優先符合公司規範
未入行之前，很多人總是好奇，英文基礎對編碼到底有沒有影響，到底有多大，這裏就可以看到，是有影響的，起碼命名的時候有障礙，需要藉助有道詞典或 code if 這樣的工具。
而且越往後英語的重要性就愈加明顯，比如你可以直接讀一手英文資料、文獻等。
最後
寫完了老感覺爛代碼這個詞用的很不好，奈何詞窮，先這麼着吧。