<bdo id="4g88a"><xmp id="4g88a">
  • <legend id="4g88a"><code id="4g88a"></code></legend>

    《代碼整潔之道》精華速覽,助你提升代碼質量

    最近重讀了一遍《代碼整潔之道》,這本書既是整潔代碼的定義,也是寫出整潔代碼的指南。我認為既適合新手閱讀,快速提升代碼質量;也適合老鳥閱讀,持續精進。本篇將匯總《代碼整潔之道》的必讀要點,把書讀薄,方便各位快速閱讀。

    為什么要閱讀《代碼整潔之道》

    第一,是個程序員;第二,想成為更好的程序員。

    一、什么是代碼整潔之道?

    有多少程序員,就有多少對整潔代碼的定義。就像武術家一樣,有不同的流派,代碼整潔也有不同的思想流派。鮑勃大叔是 「對象導師整潔代碼派」的,《代碼整潔之道》一書傳授正是這一流派的思想和方法。

    二、有意義的命名是什么樣子的?

    1. 名副其實
      例:使用有意義的名稱代替魔法數
    2. 避免誤導
      例:避免使用小寫字母l和大寫字母O作為變量名
    3. 做有意義的區分
      例:添加變量添加數字(a1、a2)、或者廢話(nameString)是沒有意義的
    4. 使用讀得出來的名稱
    5. 使用可搜索的名稱
      單字母名稱僅用于段方法中的本地變量;變量名稱應與其作用域大小相對應。
    6. 避免使用編碼
    7. 避免思維映射
    8. 類名
      類名和對象名應該是名詞或者名詞短語
    9. 方法名
      方法名應該是動詞或者動詞短語
    10. 別抖機靈
    11. 每個概念對應一個詞
    12. 別用雙關語
    13. 使用解決方案領域名稱
    14. 使用源自所涉問題領域的名稱
    15. 添加有意義的語境、不要添加沒用的語境

    三、如何寫好函數

    每個系統都是使用某種領域特定語言搭建,而這種語言是程序員設計來描述那個系統的。函數是語言的動詞,類是名詞。編程藝術是且一直就是語言設計的藝術。

    大師級程序員把系統當作故事來講,而不是當作程序來寫。他們使用選定編程語言提供的工具構建一種更為豐富且更具表達力的語言,用來講那個故事。

    寫函數需要干凈利落,這樣可以形成一種精確而清晰的語言,幫助講故事。

    1. 短小
      函數的第一條規則是要短小,第二條規則是還要更短小。
    2. 只做一件事情
      函數應該只做一件事情。做好這件事。只做一件事。
    3. 每個函數一個抽象層級
    4. 使用具有描述性的名稱
      如果每個例程都讓你感到深合己意,那就是整潔代碼。
      別害怕長名稱。長而具有描述性的名稱,要比短而令人費解的名稱好。長而具有描述性的名稱,要比描述性的長注釋好。使用某種命名約定,讓函數名稱中的多個單詞容易閱讀,然后使用這些單詞給函數取個能說清其功用的名稱。
    5. 函數參數
      函數參數越少越好,最理想的參數數量是0個。
      標識參數是丑陋不堪的,想函數傳入布爾值簡直是駭人聽聞的做法,更好的做法是將函數一分為二。
      如果函數需要2個、3個或者3個以上的參數,可以將其中一些參數封裝成類。
    6. 無副作用
    7. 分隔指令與詢問
      函數應該修改某對象的狀態,或是返回該對象有關的信息,如果兩樣都干,常會導致混亂。
    8. 使用異常代替返回錯誤碼
    9. 別重復自己
    10. 結構化編程
      結構化編程認為,每個函數、函數中的每個代碼塊都應該有一個入口、一個出口。
      鮑勃大叔雖然贊成結構化編程的目標和規范,但認為只要函數保持短小,偶爾出現的return、break或continue語句沒有壞處,甚至還比單入單出原則更具有表達力。

    四、注釋

    什么也比不上放置良好的注釋來得有用。什么也不會比亂七八糟的注釋更有本事搞亂一個模塊。什么也不會比陳舊、提供錯誤信息的注釋更有破壞性。

    好注釋與壞注釋:

    好注釋 壞注釋
    1 法律信息
    2 提供信息的注釋
    3 對意圖的解釋”
    4 闡釋
    5 警示
    6 TODO注釋
    7 放大
    8 公共API中的Javadoc
    1 喃喃自語
    2 多余的注釋
    3 誤導性注釋
    4 循規式注釋
    5 日志式注釋
    6 廢話注釋
    7 可怕的廢話
    8 能用函數或變量時就別用注釋
    9 位置標記
    10 括號后面的注釋
    11 歸屬與署名
    12 注釋掉的代碼
    13 HTML注釋
    14 非本地信息
    15 信息過多
    16 不明顯的聯系
    17 函數頭
    18 非公共代碼中的Javadoc

    五、格式

    代碼格式不可忽略。代碼格式關乎溝通,而溝通是專業開發者的頭等大事。

    5.1 垂直格式

    1. 向報紙學習
      源文件要像報紙文章那樣。名稱簡單且一目了然。名稱本身應該足夠告訴我們是否在正確的模塊中。
      源文件最頂部應該給出高層次概念和算法。細節應該往下漸次展開,直至找到源文件中最底層的函數和細節。
    2. 概念間垂直方向上的區隔
      每個空白行都是一條線索,標識出新的獨立概念。
    3. 垂直方向上靠經
      緊密相關的代碼應該互相靠近。
    4. 垂直距離
      變量聲明應盡可能靠近其使用位置。
    5. 垂直順序
      被調用的函數應該放在執行調用的函數下面,這樣可以建立了一種自頂向下貫穿源代碼模塊的良好信息流。

    5.2 橫向格式

    一行代碼應該有多寬?
    應該遵循無需拖動滾動條到右邊的原則。鮑勃大叔認為這個上限是120個字符。

    1. 水平方向上的區隔和靠近
      我們使用空格字符將彼此緊密相關的事物連接到一起,也用空格字符把相關性較弱的事物分隔開。
    2. 水平對齊(變量聲明和賦值不需要對齊)
    3. 縮進

    5.3 遵循團隊規則

    每個程序員都有自己喜歡的格式規則,但如果在一個團隊中工作,就是團隊說了算。

    六、對象和數據結構

    將變量設置為私有(private)有一個理由:我們不想其他人依賴這些變量。

    1. 數據、對象的反對稱性
      過程式代碼(使用數據結構的代碼)便于在不改動既有數據結構的前提下添加新函數。
      面向對象代碼便于在不改動既有函數的前提下添加新類。
      所以,對于面向對象較難的事,對于過程式代碼卻較容易,反之亦然!

    2. 得墨忒耳律認為,模塊不應了解它所操作對象的內部情形。

    3. 數據傳送對象
      最為精練的數據結構,是一個只有公共變量、沒有函數的類。這種數據結構有時被稱為數據傳送對象,或DTO(Data Transfer Objects)。DTO是非常有用的結構,尤其是在與數據庫通信、或解析套接字傳遞的消息之類場景中。

    對象曝露行為,隱藏數據。數據結構曝露數據,沒有明顯的行為。

    七、錯誤處理

    編寫既整潔又強固的代碼——雅致地處理錯誤代碼的一些技巧和思路。

    1. 使用異常而非返回碼
    2. 先寫Try-Catch-Finally語句
    3. 使用不可控異常
    4. 給出異常發生的環境說明
    5. 依調用者需要定義異常類
    6. 定義常規流程
    7. 別返回null值
    8. 別傳遞null值

    整潔代碼是可讀的,但也要強固??勺x與強固并不沖突。如果將錯誤處理隔離看待,獨立于主要邏輯之外,就能寫出強固而整潔的代碼。做到這一步,我們就能單獨處理它,也極大地提升了代碼的可維護性。

    八、邊界

    如何將外來代碼干凈整合進自己的代碼?這其實就是邊界的問題,邊界上的代碼需要清晰的分割和測試。

    九、單元測試

    整潔的測試有什么要素?有三個要素:可讀性,可讀性和可讀性。

    每個測試函數只測試其中一個概念。每個測試一個斷言。

    十、類

    10.1 類的組織

    遵循標準的Java約定,類應該從一組變量列表開始。如果有公共靜態常量,應該先出現。然后是私有靜態變量,以及私有實體變量。很少會有公共變量。

    公共函數應跟在變量列表之后。我們喜歡把由某個公共函數調用的私有工具函數緊隨在該公共函數后面。這符合了自頂向下原則,讓程序讀起來就像一篇報紙文章。

    10.2 類應該短小

    關于類的第一條規則是類應該短小。第二條規則是還要更短小。

    單一職責原則(SRP):類或模塊應有且只有一條加以修改的理由。

    系統應該由許多短小的類而不是少量巨大的類組成。每個小類封裝一個權責,只有一個修改的原因,并與少數其他類一起協同達成期望的系統行為。

    十一、系統

    系統也應該是整潔的。侵害性架構會湮滅領域邏輯,沖擊敏捷能力。當領域邏輯受到困擾,質量也就堪憂,因為缺陷更易隱藏,用戶故事更難實現。當敏捷能力受到損害時,生產力也會降低。

    在所有的抽象層級上,意圖都應該清晰可辨。只有在編寫POJO并使用類方面的機制來無損地組合其他關注面時,這種事情才會發生。

    無論是設計系統或單獨的模塊,別忘了使用大概可工作的最簡單方案。

    十二、逐步改進

    鮑勃大叔認為:沒什么能比糟糕的代碼給開發項目帶來更深遠和長期的損害了。進度可以重訂,需求可以重新定義,團隊動態可以修正。但糟糕的代碼只是一直腐敗發酵,無情地拖著團隊的后腿。我無數次看到開發團隊蹣跚前行,只因為他們匆匆搞出一片代碼沼澤,從此之后命運再也不受自己控制。

    注:但是,國內的開發狀況卻是不管代碼質量,只追求快速上線,只追求短期利益,而不做有長期價值的事情。
    所以,解決之道就是保持代碼持續整潔和簡單。永不讓腐壞有機會開始。

    十三、其他

    最后,我認為第17章《味道與啟發》可以作為案例來自查和學習,對提高代碼質量很有幫助。

    一起學習

    歡迎各位在評論區或者私信我一起交流討論,或者加我主頁weixin,備注技術渠道(如博客園),進入技術交流群,我們一起討論和交流,共同進步!

    也歡迎大家關注我的掘金、公眾號(碼上暴富),點贊、留言、轉發。你的支持,是我更文的最大動力!

    posted @ 2024-06-24 09:15  James_Shangguan  閱讀(867)  評論(0編輯  收藏  舉報
    免费视频精品一区二区_日韩一区二区三区精品_aaa在线观看免费完整版_世界一级真人片
    <bdo id="4g88a"><xmp id="4g88a">
  • <legend id="4g88a"><code id="4g88a"></code></legend>