代碼整潔之道

寫代碼必定要規範操做嗎？

網上不少相關的討論與回答。在此，舉個例子說明吧：

有次我被臨時借調到另外一個項目組，去幫忙趕一個需求。寫代碼的時候我犯了一個最蠢的錯誤，就是按本身的配置對代碼作了格式化。所有寫完並提交代碼後的那天中午我去醫院了。

下午接了那個項目組組長一個電話，問我提交的代碼作了哪些改動。我報了幾個路徑，並告訴了他個人修改標記。

次日到公司後，組長告訴我由於個人代碼格式與組內規範不同，致使合併測試版本的時候，幾乎每行都有差別。版本管理員不得不一行一行對比、詢問該使用哪一個版本、而後再合併、提交測試。

此次提交不到十個文件，目測實際改動的代碼行數不超過100行，可是害的版本管理員從下午兩點多一直幹到六點多才合併完版本。這仍是在我每一處修改都有修改標記的狀況下花費的時間。

我想這個例子可以說明不遵照規範的問題，和遵照規範的好處了吧！

在code看來，coder就是神，咱們能夠任性，可是咱們必定要遵照必定的規範。作人作事，咱們能夠有創新，能夠與別人不同，可是寫代碼就要規範。

不少小夥伴也是找我要一些 代碼規範 的相關資料，因而我翻箱倒櫃，找到了這本講述了一系列行之有效整潔代碼操做實踐的電子書——《代碼整潔之道》。

資料介紹

全書一共17章內容！覆蓋面廣、知識面全、案例豐富！簡直太優秀了！

讓我印象最深的仍是第四章，專門介紹註釋的一個章節，由於和實際工做簡直太貼合了。

做者舉例了好多壞註釋的類型：

喃喃自語：註釋沒有實際的意義，就好像是程序員自說自話；

多餘註釋：註釋沒有做用，並且讀註釋比讀代碼還累；

誤導性註釋：註釋不夠精準，反而誤導了讀者；

循規式註釋：滿口胡言，讓人迷惑；

日誌式註釋：冗長的註釋！這種狀況真的是常常出現呀！

……

如何獲取？

識別二維碼並關注公衆號「Java後端技術全棧」；

在公衆號後臺回覆關鍵字「303」。