程式碼整潔之道

01、有意義的命名

在團隊開發中，團隊小夥伴編碼風格各不相同，一個統一的規範就顯得尤為重要，最近在做Code Review 和程式碼優化，看到有些程式碼，實在不敢恭維，如果剛開始團隊就嚴格執行規範，也就不用花時間做這些了。編碼是一種藝術，要有一個嚴謹、欣賞的態度。

• 在開發過程中，對變數、常量、函式、引數、類等命名是一件嚴肅的事情，也是最基本的。
• 最起碼要做到見名知意，花時間起一個好的名字，可以為自己和團隊節省更多的時間。
• 《阿里巴巴Java開發手冊(終極版)》 以作參考
• 每個團隊都會有自己的規範，適合自己的才是最好的。那我就要說一句話了：“規範就是規範，執行上就是要狠一點，不僅提高自己，也是為他人省去麻煩。”

02、函式

如果你使用CheckStyle，studio 會檢查出函式最大行數是160行。在開發過程中，總會發現有那麼幾處函式體過大，各種判斷條件，看的你眼花繚亂。

• 函式規則就是短小，只做一件事。
• 使用描述性的名稱，別怕長，別怕花時間取一個易讀的名稱。
• 函式引數，沒有引數是最理想的，如果沒有足夠的理由還是不要超過三個引數。
• 分割指令與詢問，要做什麼事，要回答什麼事二者不可兼得。
• 使用異常替代返回錯誤碼。
• 抽離try/catch程式碼塊，為保證程式碼的整潔，最好把try/catch程式碼塊抽離成函式。

03、註釋

專案中的註釋也是各式各樣，統一風格也是很重要的。作為一名程式設計師，給自己的程式碼做註釋的初衷就是提高程式碼的可讀性。也許根據複雜的業務邏輯需求，會新增許多註釋，這時候就要注意格式，避免廢話。

• 一個好的、有意義的命名，會省去許多不必要的註釋。
• 有些註釋還是必要的，如：法律資訊、提供資訊的註釋、對意圖的解釋、難懂引數或返回值的闡釋、警示其他小夥伴、TODO註釋、公共函式或Api等。

04、格式

吐槽一個小夥伴的程式碼，寫程式碼全靠拷貝，註釋掉的程式碼不用了也不刪除，每次改他的程式碼都不知道從哪下手，主管也改過他的程式碼，結果也是可想而知的。能把程式碼寫到這個份上，也是沒誰了。

• 為了統一格式，我們也做了好多努力，開始code review，接入checkStyle，各種優化程式碼（最浪費時間的）。
• 豎向格式：注意豎向間隔，概念相關寫在一起、相關函式寫在一起、變數宣告寫在頂部等。
• 橫向格式：程式碼行儘量短小精悍，如果需要比較長的行並不做強制要求；同時注意水平方向上的空格；水平對齊（如bean類中修飾符、型別、名稱上下對齊）。

05、錯誤處理

記憶深刻的一件事，一位大牛在搭建某個App框架時，無網路邏輯沒有考慮進去，記得和主管聊起這件事時，主管說，作為一個搭建框架的人，這種問題是不應該出現的，無網路環境邏輯是最基本的。

• 使用異常而非返回碼，丟擲異常能很清晰的查出問題所在，而返回碼卻增加了程式碼邏輯。
• try-catch-finally 語句，定義一個範圍，丟擲異常並不影響程式碼執行。
• 不要反回/傳遞null值，否則會徒增異常風險、也會增加無謂的邏輯判斷。

06、類

• 類應該短小、符合單一職責原則。

參考《程式碼整潔之道 Clean Code》

該書介紹很詳細，在此我只關注一些程式碼整潔的部分，以便自己在編碼的道路上能更進一步。經驗看來：無規矩，不成方圓。一定的規則是非常有必要的，並且要有嚴格的執行力。