代碼整潔之道：想要成為一個更好的程式員，你要注意這些方面

在我們的認知里，工程師和程式員是有區別的，程式員是屬于那種做什么事情都是按部就班，沒什么獨立思考能力，但其實，程式員也可以看做是工程師，他們有工程師的思維，做一個專案需要考慮全域，

編程和寫作都是在構建自己的世界，作家可以用文字構建自己的世界，在那個世界里，他想要什么樣的角色，自己去生成，編程跟寫作有共通之處，編程也是在構建自己的虛擬世界，在這個世界里可以去做一些他想做的事情，

跟文字一樣，編程語言沒有高低之分，真正的工程師需要掌握多種語言，工程師的作用就是他知道這個地方用什么語言實作最好，

但是除了會寫代碼，代碼的整潔程度也很重要，這不僅僅讓自己理清思路，也能方便他人看懂我們的代碼，提高效率，

普通的工程師堆砌代碼，優秀的工程師優雅代碼，卓越的工程師簡化代碼，如何寫出優雅整潔易懂的代碼是一門學問，也是軟體工程實踐里重要的一環，

一本很有名的書籍《代碼整潔之道 》，推薦大家去看看，

本篇文章重點將從注釋、命名、方法、例外、單元測驗等多個方面總結了一些代碼整潔最佳實踐，

注釋

• 不要給不好的名字加注釋，一個好的名字比好的注釋更重要

• 不要“拐杖注釋”，好代碼 > 壞代碼 + 好注釋

• 在檔案/類級別使用全域注釋來解釋所有部分如何作業

• 一定要給常量加注釋

• 團隊統一定義標記

TODO 待處理的問題
FIXME 已知有問題的代碼
HACK 不得不采用的粗糙的解決方案

• 在注釋中用精心挑選的輸入輸出例子進行說明

• 注釋應該宣告代碼的高層次意圖，而非明顯的細節

• 不要在代碼中加入代碼的著作資訊，git可以干的事情不要交給代碼

• 源代碼中的html注釋是一種厭物, 增加閱讀難度

• 注釋一定要描述離它最近的代碼

• 注釋一定要與代碼對應

• 公共api需要添加注釋，其它代碼謹慎使用注釋

典型的爛注釋

不恰當的資訊
廢棄的注釋
冗余注釋
糟糕的注釋
注釋掉的代碼

• 唯一真正好的注釋是你想辦法不去寫的注釋

不要有循規式注釋，比如setter/getter注釋
不要添加日志式注釋，比如修改時間等資訊（git可以做的事情）
注釋一定是表達代碼之外的東西，代碼可以包含的內容，注釋中一定不要出現
如果有必要注釋，請注釋意圖（why），而不要去注釋實作（how)，大家都會看代碼
適當添加警示注釋

命名

• 盡可能使用標準命名方法，比如設計模式，通用學術名詞等

• 命名要找更有表現力的詞

使用更專業的詞，比如不用get而使用fetch或者download
避免空泛的名字，像tmp
使用具體的名字來細致的描述事物
給變數名帶上重要的細節，比如加上單位ms等
為作用域大的名字采用更長的名字，作用域小的使用短名字
變數型別為布林值表達加上is，has，can，should這樣的詞會更明確

• 變數名稱長短應該與其作用域對應

• 別害怕長名稱，長而具有描述性的名稱比短而令人費解的名稱好

• 函式名稱應該說明副作用，名稱應該表達函式，變數或類的一切資訊，請不要掩蓋副作用，比如CreateAndReturnXXX

方法

• 函式不應該有100行那么長，20行封頂最好

if else while等控制陳述句其中代碼塊應該只有一行，也就是一個函式呼叫陳述句
函式的鎖進層次不應該多于兩層
一個函式只做一件事，一個函式不應該能抽象出另外一個函式

• 某個公共函式呼叫的私有函式緊隨其后

• 最理想的引數是零引數，最長不要超過三個入參，盡量不要輸出引數

如果函式傳入三個及以上引數最好將其抽象為類
標識引數十分丑陋，向函式傳入布林值用于區分不同業務的做法很丑陋，應該拆分為多個函式

• 別回傳null值，拋出例外或者回傳特殊物件，盡量避免NPE

• 別傳入null值

例外與錯誤

• 抽離try catch包含的代碼塊，其中代碼塊抽象為一個函式

• 拋出的每個例外，都應當提供足夠的環境說明，已便判斷錯誤的來源與處所

• 不要將系統錯誤歸咎于偶然事件

并發

• 分離并發相關代碼與其它代碼

• 嚴格限制對可能被共享的資料的訪問

• 避免使用一個共享物件的多個同步方法

• 保持同步區域微小，盡可能少設計臨界區

單元測驗

• 不要怕單元測驗的方法名字太長或者繁瑣，測驗函式的名稱就像注釋

• 不要追求太高的測驗覆寫率，測驗代碼前面90%通常比后面10%花的時間少

• 使用最簡單的并且能夠完整運用代碼的測驗輸入

• 給測驗函式取一個完整性的描述性名字，比如 Test _

• 測驗代碼與生產代碼一樣重要

• 如果測驗代碼不能保證整潔，你就會很快失去他們

• 每個測驗一個斷言，單個測驗中斷言數量應該最小化也就是一個斷言

• FIRST原則

快速 Fast

• 獨立 Independent 測驗應該相互獨立

可重復 Repeatable 測驗應當在任何環境中重復通過
自足驗證 Self-Validating 測驗應該有布林值輸出
及時 Timely 最好的方式是TDD

獨立 Independent 測驗應該相互獨立
可重復 Repeatable 測驗應當在任何環境中重復通過
自足驗證 Self-Validating 測驗應該有布林值輸出
及時 Timely 最好的方式是TDD

代碼結構

• 代碼行長度控制在100-120個字符

• 可能用大多數為200行，最長500行的單個檔案構造出色的系統

• 關系密切的代碼應該相互靠近

變數宣告應該靠近其使用位置
若某個函式呼叫了另外一個，應該把他們放在一起，而且呼叫者應該放在被呼叫者上面
自上向下展示函式呼叫依賴順序

• 應該把解釋條件意圖的函式抽離出來，盡可能將條件表達為肯定形式

• 不要繼承常量，比如介面中定義常量，不要使用繼承欺騙編程語言的作用范圍規則

• 模塊不應了解它所操作物件的內部情況

• DTO（Data Transfer Objects）是一個只有公共變數沒有函式的類

• 物件暴露行為，隱藏資料

• 不要使用“尤達表示法” 如 if(null == obj)，現代編譯器對if(obj = null)這樣的代碼會給出警告

• 一般情況使用if else，簡單陳述句使用三目運算子

• 通常來講提早回傳可以減少嵌套并讓代碼整潔

設計

• 類應該足夠短小

類應該滿足單一權責原則（SRP），類和模塊只有一個修改理由
類應該只有少量的物體變數
類應該遵循依賴倒置原則 DIP（Dependency Inversion Principle），類應該依賴于抽象而不是依賴于具體細節
類中的方法越少越好，函式知道的變數越少越好，類擁有的物體變數越少越好

• 通過減少變數的數量和讓他們盡量“輕量級”來讓代碼更有可讀性

減少變數
縮小變數的作用域
只寫一次的變數更好，如常量

• 最好讀的代碼就是沒有代碼

從專案中消除不必要的功能，不要過度設計
從新考慮需求，解決版本最簡單的問題，只要能完成作業就行
經常性地通讀標準庫的整個API，保持對他們的熟悉程度

• 簡單設計

運行所有測驗
不可重復
表達了程式員的意圖
盡可能減少類和方法的數量
以上規則按重要程度排列

• 無論是設計系統或者單獨模塊，別忘了使用大概可作業的最簡單方案

• 整潔的代碼只提供一種而非多種做一件事的途徑，他只有盡量少的依賴，明確定義并提供盡量少的API

• 減少重復代碼，提高表達力，提早構建，簡單抽象

   

相信每一個優秀的工程師都有一顆追求卓越代碼的心，在代碼整潔工程實踐上你有哪些好的建議？一起來討論看看吧~

本文作者：竹澗

如果你想提升你的編程能力，以便更好從事編程類作業的話！那么你很幸運~分享（原始碼、專案實戰視頻、專案筆記，基礎入門教程）歡迎轉行和學習編程的伙伴，利用更多的資料學習成長比自己琢磨更快哦！

點我進入學習基地

標籤：其他

上一篇：巴西最大惡意銀行軟體制造者—來自象牙塔里年僅20歲的LdFx

下一篇：隨便聊一聊&最近做的專案