2013年10月31日 星期四

無瑕的程式碼心得記錄(一)

這篇是無瑕的程式碼的心得筆記.....

有意義的命名

  • 讓名稱帶表意圖
    • 讓名稱名符其實
  • 避免誤導
  • 產生有意義的區別
  • 使用能唸出來的名稱
  • 使用可被搜尋的名字
  • 避免編碼
  • 避免思維的轉換
    • 清楚明白才是王道
  • 類別的命名
    • 使用名詞或名詞片語命名
  • 方法的命名
    • 使用動詞或動詞片語
  • 不要裝可愛
    清楚闡述比起娛樂價值來的重要
  • 每種概念使用一種字詞
    Ex:取得方法不要fetch、retrieve又get
  • 別說雙關語
  • 使用解決方案領域的命名
  • 使用問題領域的命名
  • 添加有意義的上下文資訊(context)
  • 別添加無理由的上下文資訊

函式

  • 簡短
  • 只做一件事
  • 每個函式只有一層抽象概念
    • 降層準則
      • 由上而下閱讀程式碼
  • 使用具描述能力的名稱
  • 函式的參數
    • 參數數量
      • 最理想是零個
      • 其次是一個
      • 盡量避免超過三個參數
    • 物件型態的參數
      • 可減少參數的數量
    • 輸出型的參數
      • 避免使用
  • 動詞和關鍵字
    • 替函式取個好名稱可產生許多良好的附加價值
  • 要無副作用
    • 一次只做一件事,不要在函式底下偷做其他事
  • 指令和查詢要分離
    函式要能做某事或能回答某個問題,但二者不該同時發生
  • 使用例外處理取代回傳錯誤
    • 錯誤處理就是一件事
  • 不要重覆自己(DRY)
  • 結構化程式設計
    • 每個函式及函式裡的區塊都應該只有一個進入點及一個離開點
    • 不能有break或continue敍述
    • 永遠不能有goto敍述
  • 如何寫出這樣的函式
    • 像寫文章一樣
      • 初稿通常粗糙而雜亂無章
      • 重新組織整個文章段落,將文章改善至你要的樣子

註解

  • 不要替糟糕的程式碼寫註解—重寫它
  • 註解無法彌補糟糕的程式碼
  • 用程式碼表達你的本意
  • 有益的註解
    • 法律型註解
    • 資訊型註解
      • 透過註解提供一些基本資訊是非常有用的
    • 對意圖的解釋
    • 闡明
      • 把難解的參數或回傳值翻譯成具有可讀性的文字
    • 對後果的告誡
      • 做為一種警告
    • 待辦事項註解
    • 放大重要性
  • 糟糕的註解
    • 喃喃自語
    • 多餘的註解
      • 有時候程式碼本身就可以提供明白的意圖,加了註解反而比程式碼更難理解
    • 誤導型註解
      • 不精確讓人看不懂
    • 規定型註解
      • 因為規定加上去的註解,有時候反而會產生更多困惑或造成散亂的程式結構
    • 日誌型註解
      • 現在有好的原始碼管控系統,可以不需要
    • 干擾型註解
      • 某些註解毫無用處,只會干擾
  • 可以使用函式或變數時就別使用註解
  • 位置的標誌物
  • 右大括號後面的註解
  • 出處及署名
  • 被註解起來的程式碼
  • 非區域性的資訊
  • 過多的資訊
  • 不顯著的關聯
  • 函式的標頭
    • 為小型函式選一個好的名稱,通常比「將註解寫在函式標頭」來的更優

編排

  • 編排的目的
    • 讓程式碼更具可讀性
  • 報紙的啟發
    • 頭條的敍述
    • 概要
    • 全文細節
  • 垂直的編排
    • 概念間的垂直空白區隔
      • 用空白來分隔不同的思緒
        • 宣告
        • 引用類別庫
        • 不同函式
    • 垂直密度
      • 程式密切相關的程度
        • 密切相關的程式應該垂直緊密,不要被無用的註解或其他的程式碼切開其關聯性
    • 垂直距離
      • 具類似的概念應盡可能的靠近
      • 變數宣告
        • 應盡可能靠近變數使用的地方
      • 實體變數
        • 應被宣告在類別的上方
      • 相依的函式
        • 如果A函式呼叫了B函式,那麼這二個函式在垂直編排上要盡可能靠近
      • 概念相似性
        • 概念上有相似性質的程式碼盡可能的相近
      • 垂直的順序
        • 呼叫敍述應在被呼叫函式的上方
  • 水平的編排
    • 水平的空白間隔和密度
      • 高度相關及完全不相關的事情,都可以利用水平的空白將之分開
      • 設定運算子(assignment operators)
      • 強調運算子的優先權
    • 水平的對齊
      • 沒有必要
      • 長度會太長
    • 縮排
      • 階層結構
      • 讓視野層次結構更顯而易見
      • 違反縮排的規則
        • 有時候因if、while或簡短的函式想違反縮排的規則
        • 盡量不要
      • 空視野範圍
        • While或for迴圈的程式是空白
        • 確保空白區塊也被縮排,否則很容易被誤導
  • 團隊的共同準則
    • 統一的編排規則

物件及資料結構

  • 資料抽象化
  • 資料/物件的反對稱性
    • 結構化的程式碼容易添加新的函式,而不需要變動已有的資料結構。而物件導向的程式碼,容易添加新的類別,而不用變動已有的函式。
    • 結構化的程式碼難以添加新的資料結構,因為必須改變所有的函式。物件導向的程式碼難以添加新的函式,因為必須改變所有的類別。
  • 德摩特爾法則(The Law of Demeter)
    • 類別C內的方法f,應該只能呼叫以下事項的方法
      • C
      • 任何由f所產生的物件
      • 任何當作參數傳遞給f的物件
      • C類別裡的實體變數所持有的物件
    • 方法不該呼叫「由任何函式所回傳之物件」的方法
  • 資料傳輸物件(Data transfer Objects,DTO)
    • 最佳的資料結構形式
    • 類別裡只有公用變數,沒有任何函式

沒有留言:

張貼留言