代碼整潔之道

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

網上不少相關的討論與回答。在此,舉個例子說明吧:程序員

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

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

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

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

我想這個例子可以說明不遵照規範的問題,和遵照規範的好處了吧!代碼規範

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

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

資料介紹it

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

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

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

喃喃自語:註釋沒有實際的意義,就好像是程序員自說自話;

多餘註釋:註釋沒有做用,並且讀註釋比讀代碼還累;

誤導性註釋:註釋不夠精準,反而誤導了讀者;

循規式註釋:滿口胡言,讓人迷惑;

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

……

代碼整潔之道

如何獲取?

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

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

相關文章
相關標籤/搜索