Clean Code隨筆筆記整理

Ch1. Clean code

好的程式碼應具有以下特質
  1. 能通過所有測試
  2. 沒有重複的程式碼
  3. 能充分表達意思
  4. 內容很短,最少量的class、Method \ Function存在
  5. 盡量少的互相依賴關係
  6. 有意義的命名,應該要光看遍數名就能懂這個變數的存在用意

Ch2. 有意義的命名

  • 請讓命名能夠展現他的意圖。
  • 不要用一些自己才知道是什麼意思的方式來命名:Image for post
  • 取名不應太過相似,要有明確區別
    reports
    report_list
    the_reports 都是複數的報告,請問誰是誰

  • 使用一些Searchable,可被IDE搜尋的到的名稱(不要跟撞名或前面掛一堆一樣的前綴增加搜尋難度或演殘選錯的機會)
  • Class和Instance不要同名
  • 用m來代表class的member前綴不是很必要,可以直接用this

  • 避免想到甚麼就打甚麼,可以的話明確定義。ex: for(int i = 0) <=可以的話就不要用i了,告訴他 i是甚麼吧

  • 變數、class、object應該使用「名詞」或名詞片語來命名
  • Function應該使用「動詞」或動詞片語來命名

  • 取名時盡量避免雙關。ex : Add就有 數學加法 和 加上、添上的意思。
    像後者的話我們可以取名為append或extend
  • 通常看你code的都會是工程師,取名以工程師看得懂為主,不需要刻意取得太過艱深。
  • 如果日常單子不足以應付取名,再以專案需求領域的專業術語單字來取名。

Ch3. Function

  • Function內容要盡量輕量短小為好
  • 一個Function只做一件事,也只做好一件事
  • 一個Function只作一個層級的事。抽象層級:
    https://www.itread01.com/content/1520062710.html
    (看起來跟作用範圍有關)

    ex: getHtml();//高層級
          String pagePathName = PathParser.render(pagePath) //中層級
          .append("\n") //低層級

  • 「由上至下閱讀原則」,由上層層級開始往下層level編寫

  • 最好的參數類型就是沒有參數
  • 如果一個function需要到兩個以上參數,可以考慮把參數包成class來傳給function

Ch4. 註解

  • 有益的註解;對意圖做解釋
  • 寫//TODO註解告訴大家有哪些事 「要做」 「還沒做」 「現狀」 及 「未來預計的狀況」
  • 同時定期刪掉已不再需要的TODO

  • 程式碼作者現在通常已經可以在git中找到,不見得需要寫成comment
  • 盡量不要註解程式碼,刪掉他保持畫面乾淨
  • 講重點,避免註解內容過多

Ch5. 編排排版

  • 垂直格式,注意空白
  • 讓換行距離成為關係緊密的依據之一,比較無關的可以隔遠一點
  • 被呼叫的function其實作內容,應該要出現在執行呼叫function的下方
  • 水平方向盡量切齊,不要拉的太長。

Ch6. 物件與資料結構

  • 資料結構 : 資料直接暴露在外,任何人都可以對其資料隨意存取。
  • class物件 : 物件內的資料可以透過private來隱藏,提供member function供大家使用

  • 程序語言 與 物件導向語言 的差別 : 
  • Procedural Code :當程序語言要加入新的或修改資料結構時會顯得比較麻煩,會有一堆function需要修改。但是加入新function顯得較為容易
  • 物件導向程式語言 : 物件導向程式語言在加入新function時顯得比較麻煩,因為class會需要被修改。但是在建立或修改class則顯得比較方便

  • 德模特爾原則 : 又稱最少知識原則。

    Class的member function A只能呼叫使用:
    1. function A自己
    2. function A所建立的東西
    3.傳給了 function A得參數
    4.Class內的data member

    就讓Class / function用他所知道的事情做事就好了,不應該讓function知道太多事情。可能像是全域變數就不太能給function用。已經超出他所知的範圍了

Ch7. 錯誤處理

  • 使用try - catch代替使用一堆if- else來抓錯誤立flag
  • 不要return null或pass null。 如果接不起來怎麼辦,可以回傳一個內容資料是空的相應物件
  • 不要把try - catch當if - else用。可以採用Design Pattern中的特殊情況模式來處理(另外開一個case來處理)

Ch8. 邊界

邊界感覺就像是自己現在的程式,與第三方程式 及 未來未知的程式, 的範圍區塊。
  • 學習式測試,知道第三方程式大概在幹嘛,如何整合進專案裡,要怎麼修改?
  • 學習式測試包含 : 邊界測試  單元測試

  • 邊界測試 : 程式在極端 / 偏門情況下會發稱什麼狀況
  • 單元測試 : 針對程式軟體模組最小單位 做 驗證的測試


  • 使用Adapter pattern模式來為「還不知道實作內容」或「未來可能會修改」的程式或第三方程式做接界到自己的程式來使用,相當於寫一個controller去控制別人的程式。除了可以作假內容方便自己開發。未來如果他人的程式修改,自己也只需要修改controller端的程式就好,本身主程式不需要大幅修改

Ch9. 單元測試

  • 測試code跟內文code一樣重要,同樣需要乾淨的維護
  • 有些有針對特定領域的測試語言,包成API來使用
  • 同樣,一個測試code一個概念

  • 整潔測試原則 : 

  • 測試執行速度要快
  • 一個測試要能獨立進行,不和其他測試相依
  • 測試在任何情況 / 環境下都能執行
  • 測試結果要能回傳bool值告訴大家是否成功,讓人清楚知道那些有過那些沒過
  • 測試先寫過,再來寫產品程式

Ch10. Class

  • class內容應該要短小
  • class的名稱應該要描述他的權責
  • class的變數應該要能盡量少。
  • class的data function應該要能用到一個以上的data member
  • 單一職責原則: 一個class只有一個權責。不要做太多事情。

  • 系統應是由多個小class構成,而不是一個巨大的class
  • 每個class封裝一個權責功能,和其他class一起完成系統

  • 修改能夠具封閉性,不會改一邊就一堆其他地方需要改。盡量不要牽一髮動全身
  • 隔離修改:Adapter pattern

Ch11.  System

先來看看別人的心得:
未提供相片說明。

QQ

留言

這個網誌中的熱門文章

UE4 tutorial : Blueprints 筆記

UE4 tutorial : Materials 筆記

UE4 tutorial : Getting Started