l

2013年4月19日 星期五

Clean Code之有意義的命名

Apr. 12 22:10~23:21

image

今天翻了一下Clean Code第2章「Meaningful Names」(有意義的命名),書中介紹了好幾條關於變數命名的技巧:

  1. Use Intention-Revealing Names
  2. Avoid Disinformation
  3. Make Meaningful Distinctions
  4. Use Pronounceable Names
  5. Use Searchable Names
  6. Avoid Encodings
    • Hungarian Notation
    • Member Prefixes
    • Interfaces and Implementations
  7. Avoid Mental Mapping
  8. Class Names
  9. Method Names
  10. Don’t Be Cute
  11. Pick One Word per Concept
  12. Don’t Pun
  13. Use Solution Domain Names
  14. Use Problem Domain Names
  15. Add Meaningful Context
  16. Don’t Add Gratuitous Context

建議項目居然多達16項。不過話說回來變數命名這件事的確是非常重要,但一般的程式設計或開發書籍相對而言卻鮮少談論的一個主題。Kent Beck的《Implementation Patterns》這本書有提到一些,像是Intention-Revealing Name這個技巧在《Implementation Patterns》就有介紹。

Teddy當然不會把這16個項目]全部寫在部落格上,不然可能被告…不是啦,應該是說書上寫得很清楚,有興趣的鄉民們買本書回家看。Teddy今天想談的是「Avoid Encodings」這個項目的三個子規則。

Hungarian Notation

Hungarian notation (匈牙利表示法)在古早、古早的Windows C API與MFC類別庫中廣泛地被使用,年長如Teddy(…Orz),當年也「學到」這個方法因此沿用了好一陣子。例如:

String sAddress;

int iCounter;

Handle hWnd;

Teddy記得完整的匈牙利表示法還有點小複雜,最常見的規則就是用前置字元代表變數的型態或是scope。由於現代的整和開發環境(IDE,例如Eclipse)都已十分先進,不需要使用這種表示法(命名方法)來避免變數型別錯用。而且這種方法嚴格講起來算是違反了「資訊隱藏」,所以身為現代人的你可以不要再繼續沿用匈牙利表示法。

但是Teddy要補充說明一點,在Clean Code書中作者主要舉例的語言是Java,雖然匈牙利表示法對Java或C#這種語言也許不太合用,但Teddy自己的經驗,在C語言中使用匈牙利表示法還是滿普遍的,提供給鄉民們做為參考。

***

Member Prefixes

不要在類別的成員變數(Class的member variable或是data member)之前加上「m」這個字首。這個習慣其實也是匈牙利表示法的遺毒之一,用來協助開發人員判斷變數的scope。不過現代的IDE大多可以自動將成員變數以不同的顏色顯示,所以這條規則也可以免了。

談白說Teddy一直有在成員變數之前加上m的習慣,以前甚至把這一條列入開發團隊的coding standard裡面。著名的JUnit工具,也會在成員變數之前加上f這個字首(應該是field的意思)。不過當年Teddy使用Eclipse的時候,還沒有自動以不同顏色的字區隔成員變數的功能,也許現在該是丟棄這個習慣的時候了,好掙扎啊挑眉質疑


螢幕快照 2013-04-12 下午10.55.58

在Eclipse中,成員變數用藍色的字以示區別。

***

Interfaces and Implementations

這一條是建議不需要幫介面(interface)的名字加上I這個字首,例如IConfigParser。至於實作類別,則可在自尾加上Imp(有人會加上Impl),例如ConfigParserImp。

看到這一條,Teddy內心又有點天人交戰。關於實作的命名這一點倒是沒什麼爭議,Teddy也是會在字尾加上Imp或是Impl。但是Teddy以前的習慣是會在介面前面加上一個I字母,不過後來使用很多Java類別庫,在介面前面加上I的作法的確是屬於比較少數。所以這個習慣也許以後要考慮改過來。

***

寫到這邊,Teddy覺得其實只要是團隊有自己熟悉的coding standard,習慣成自然之後,除非發現有什麼窒礙難行之處,否則就算自己的coding standard與Clean Code書中所建議的不同,也不一定要急著去改變。畢竟古人有云:「盡信書不如無書」啊熱戀

怎麼回事,整篇讀完怎麼覺得這次又是來「吐臭」的挑眉質疑

***

友藏內心獨白:這是補充說明,不是「吐臭」啦。

5 則留言:

  1. 我習慣是只有底線,因為我不想打this.

    回覆刪除
  2. interface習慣用大I開頭...

    回覆刪除
  3. 不用介意"吐臭"兩個字啊(詳見我在Clean Code裡面的第一篇回覆),歡迎吐臭,還期望有一天,您可以幫我寫個評注版呢,ㄎㄎ

    回覆刪除
  4. 大名鼎鼎的Visual Sutdio 2010就不會幫C++ member variable上色,所以在我們團隊裡,m_variable還是必須的。

    回覆刪除
    回覆
    1. 所以說盡信書不如無書,書上所寫的建議還是要自己判斷一下。

      刪除