總結關於【程式碼中的壞味道】

• 2019 年 10 月 10 日
• 筆記

程式碼檢查工具方法建議是不要超過80行，這只是一個參考標準而已。這樣做的目的是：如果超過80行，閱讀起來會相對費勁。也見過上千行的方法，這種超級方法不管注釋寫得再好、程式碼命名再規範，對於閱讀的人來說，都是一種痛苦。

解決辦法：首先，看能不能把業務拆分一下。分成幾步：先幹什麼、再幹什麼、最後幹什麼。其次，給一個對象set參數時候，看能不能封裝成一個方法，因為這部分程式碼就僅是set參數而已，跟業務關係不大的。比如：第一步，校驗方法入參；第二步，業務處理；第三步，組裝返回參數。把一個大方法拆分成多個小方法。

在百分之九十九的場景中，要把方法變小，將方法中適合集中的部分，提煉出來形成一個新方法。

02 程式碼重複

使用IDEA的小夥伴應該都知道，如果你的程式碼存在重複，那麼重複的程式碼顏色會變的，把滑鼠放上去就會提示你存在多個一毛一樣的程式碼，建議你使用同一塊程式碼。

解決辦法：把共同程式碼塊提取出來。通常做法是提取成一個方法，然後有使用到的地方，調用這個方法即可。

03 程式碼起名

一個項目開發出來，如果不review程式碼，不做規範，後期很容易出現「同一個業務名出現各種各樣的英文名」的情況。比如說：賬戶通常翻譯成account，但是有的人寫成acct，有的人寫成amount（這個我是見過的）。這也是因為程式碼中需要起名字的地方太多了：類名，方法名，常量名，變數名……

解決辦法：最好是開發的時候搞一個常見命名單詞庫，要什麼單詞先去裡面查一下，是否已經存在了。對於不存在的，大家一起商量著怎麼命名，確定了後將其寫到單詞庫。久而久之，大家就形成習慣了，後面有新人來接手老程式碼的時候，對於有歧義的單詞就可以直接查看單詞庫。

04 神奇的魔法數字

項目開發中經常會遇到if(age==25)....。請問這個25代表什麼？還有setStatus(0)這是什麼意思？如果程式碼沒有做review，大約99%的程式碼里都會出現這樣類似的魔法數字。我之前接觸過一段老程式碼，寫著：

if(amount==200){      ...  }else{      ...  }

當我去問前輩們的時候，人家回我一句就是：if里的程式碼從來就沒走過，一直是走else里的程式碼，記住就可以了。

解決辦法：1）搞常量類，把一些常量類放進去，統一管理並寫好注釋；2）搞成枚舉類，把部分相關聯的魔法數字寫到枚舉中統一管理並寫好注釋。

05 過多的或者無注釋

網上流行一句話：請保證你的程式碼有效期更長一點。如果關鍵地方不寫注釋，即使是自己寫的程式碼，很多時候回溯也會一時半會想不起來那到底是個什麼東東。交給人來閱讀並維護你的程式碼，對方心情可想而知……

但是也不是說寫了注釋，就沒問題了。有的人愛學JDK源碼、其他框架源碼，學到了人家一個類里寫了大量的注釋，結果咋項目中他也把那種思想用起來了。本來是好事，但是由於注釋過多，加上漢語博大精深。看完對方的注釋後，會感覺雲里霧裡，不知道在說什麼……

解決辦法：注釋盡量簡單明了，淺顯易懂。實在無法描述的地方，你可以使用demo案例來說明，具體可以參考JDK、Spring等框架中大神們的注釋。

06格式化程式碼

為什麼要格式化呢？我們在開發的時候，可能多個人對同一個文件進行修改，比如A寫一個類，但是程式碼沒有格式化，然後把程式碼提交上去，這時候B把你程式碼拉下來改動一部分，然後格式化了程式碼，但是B還沒有提交，然後A也再次把本地程式碼改了一部分，B把程式碼提交了，B這時候是無法提交程式碼的，只能先更新程式碼。那麼問題來了，B已經把程式碼格式化了，A得合併程式碼，A合併的時候會發現B把程式碼大面積改動了，甚至A得細心的看每一行程式碼，其實很有可能B只改一行程式碼，但是由於B格式化了程式碼，A沒有格式化。這樣會導致A花大量時間在合併程式碼上。為了避免這種問題的出現 ，建議在提交程式碼前進行格式化程式碼。另外一個問題就是程式碼格式化後對於閱讀更加賞心悅目。原始程式碼：

格式化後：

IDEA中使用快捷鍵：

Ctr+Alt+L或者選中你要格式化的程式碼然後Ctr+Alt+L

以上是這段時間所遇到的，這裡總結一下，希望對大家有用。大家對下面這段程式碼有何評價