如何寫出簡潔、高效的代碼?

給親推薦一篇阿里巴巴高級開發工程師竹澗分享的關于代碼整潔之道的一篇文,希望對你有所幫助 。
Any fool can write code that a computer can understand. Good programmers write code that humans can understand.普通的工程師堆砌代碼,優秀的工程師優雅代碼,卓越的工程師簡化代碼 。如何寫出優雅整潔易懂的代碼是一門學問,也是軟件工程實踐里重要的一環 。筆者推薦三本經典的書籍《代碼整潔之道 》、《編寫可讀代碼的藝術》、《重構:改善既有代碼的設計》,下文重點將從注釋、命名、方法、異常、單元測試等多個方面總結了一些代碼整潔最佳實踐,大部分是筆者總結于以上三本書中的精華,也有部分是筆者工程實踐的總結 。篇幅有限,本文將總結性給出一些實踐建議,后續會有文章來給出一些代碼整潔之道的事例 。
注釋
不要給不好的名字加注釋,一個好的名字比好的注釋更重要不要“拐杖注釋”,好代碼 > 壞代碼 + 好注釋在文件/類級別使用全局注釋來解釋所有部分如何工作一定要給常量加注釋團隊統一定義標記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
代碼結構
代碼行長度控制在100-120個字符可能用大多數為200行,最長500行的單個文件構造出色的系統關系密切的代碼應該相互靠近變量聲明應該靠近其使用位置若某個函數調用了另外一個,應該把他們放在一起,而且調用者應該放在被調用者上面自上向下展示函數調用依賴順序

推薦閱讀