程式設計注意事項 - 2008.08.17 update

by thinker

關鍵字:

幾個注意事項，隨時更新

這些只是建議性原則，將日常遇到的原則問題和解決方法表列。曾在別人的 $blog$ 看到有人提起這篇 memo，表示無法了解規則背後的理由。規則陳述句會盡量精簡，所以並不是每個人都可以看懂。也許像推背圖，事情發生時就會晃然大悟，原來如此 :p 當然，這個 memo 不像推背圖精深、博大。

* 變動和影嚮
  * class 或 module 之間，必需依靠 interface 溝通。
  * 依靠其它 class 或 module 的結構，容易受其結構變動而影嚮。
  * interface 容易適應(adapt) implement 的改變； interface 不變。
  * 將 class 或 module 之間的相關性，集中和局限於小範圍，易於變動。
  * interface 透過適應程序，能集中和局限因變動而受影嚮的範圍。
  * 先確定 class 、 module 或 interface 的關聯，再寫程式。 2007.02.23
  * 關聯圖，不離手。 2007.02.23
  * 避免、減少 interface 的間接曝露。 2007.02.23
* Closure 代替 function object
  * 使用 closure 比 function object 好。
  * closure 能減少程式碼。
  * closure 將 callback 所需資料，集中在小範圍的 source code  內 (static scope)。
  * closure 改善閱讀性。
* 功能切割
  * 每個 class 維護單一目標所需的資料。
  * function 或 method 提供單一目的。
  * 達成目的所需的相關動作，各自分割成 function 、 method 或 class。
    * 資料加入資料庫之後，index 必需更新，則加入動作呼叫 index 更新的 function 或 method，而非全由加入動作獨力完成。
  * 若 class 提供大量 callback 的 method, 可考慮以一個或多個 interface 組織 callback methods. 形成 top-down 形式, 較簡單的 topology. (update: 2006.11.28)
* 命名規則
  * function 名稱必需有動$詞$
  * function parameter 是名$詞$
  * parameter 出現的順序依照 function 名稱中出現的次序
  * 名$詞$可被省略，但 parameter 出現的次序應該依照原本的次序
  * method 的 bond object 是主$詞$
* 語法使用
  * 一行一動作, 一行多動作不利於 debug
  * 一行一 function, 呼叫多個 function 不易 debug (錯在哪個 function?)
  * 限制括號的層數，不論是大、中、小括號。
    * 太多層的括號，可將之中間的計算過程拆成數行，以利於閱讀。

最後更新時間: 2008-08-17 08:47:58 CST | 引用

查詢:

COMMENTS:

on 2007-02-24 16:08:23 CST

遊手好閒的石頭成 said ..

這 memo 中，有些是編程事項，有些是語言事項，有些是寫作事項。有些內容僅適用於特定語言。例如在 C,C#,JavaScript 中，只有 function object 而沒有 closure ，所以只能用 function object ；C# 和 JavaScript 支持 anonymous function ，那就是它們的 closure 。「parameter 出現的順序依照 function 名稱中出現的次序」，這似乎是 C 式的命名規則，在動態語言與支援函數覆載的語言中，函數名稱多數只有單純的動詞。