來吧
日常編碼少不了的事情就是給代碼命名，代碼中命名的重要性在項目前期不會有太大感受，因為是邊做邊命名，代碼天天見，自然會加深記憶。但到了后期上線后半年一年后，再回過頭看的時候，我擦，這個變量是啥意思？這個方法不對呀，不是更新用戶狀態的嗎？ 接下來就是各種吐槽，誰寫的代碼，這么爛，翻一下提交日志，哦？我寫的，趕緊悄悄的改過來。
經常性我們吐槽別人的代碼爛，那么你是如何定義你認為的爛代碼，它們爛在哪里 ?
代碼究竟爛在哪里
這個問題說的具體點，可能經常我們在沒理清業務邏輯的情況下去直接看別人的代碼，相當於通過代碼反推業務邏輯，別人的命名、編程思維跟自己的習慣不一致，需要時間去消化理解他的邏輯和習慣，然后加上代碼排版亂七八糟，一堆 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 這樣的工具。
而且越往后英語的重要性就愈加明顯，比如你可以直接讀一手英文資料、文獻等。
最后
寫完了老感覺爛代碼這個詞用的很不好，奈何詞窮，先這么着吧。