Apr. 12 22:10~23:21
今天翻了一下Clean Code第2章「Meaningful Names」(有意義的命名),書中介紹了好幾條關於變數命名的技巧:
- Use Intention-Revealing Names
- Avoid Disinformation
- Make Meaningful Distinctions
- Use Pronounceable Names
- Use Searchable Names
- Avoid Encodings
- Hungarian Notation
- Member Prefixes
- Interfaces and Implementations
- Avoid Mental Mapping
- Class Names
- Method Names
- Don’t Be Cute
- Pick One Word per Concept
- Don’t Pun
- Use Solution Domain Names
- Use Problem Domain Names
- Add Meaningful Context
- 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的時候,還沒有自動以不同顏色的字區隔成員變數的功能,也許現在該是丟棄這個習慣的時候了,好掙扎啊。
在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書中所建議的不同,也不一定要急著去改變。畢竟古人有云:「盡信書不如無書」啊。
怎麼回事,整篇讀完怎麼覺得這次又是來「吐臭」的。
***
友藏內心獨白:這是補充說明,不是「吐臭」啦。
我習慣是只有底線,因為我不想打this.
回覆刪除interface習慣用大I開頭...
回覆刪除不用介意"吐臭"兩個字啊(詳見我在Clean Code裡面的第一篇回覆),歡迎吐臭,還期望有一天,您可以幫我寫個評注版呢,ㄎㄎ
回覆刪除大名鼎鼎的Visual Sutdio 2010就不會幫C++ member variable上色,所以在我們團隊裡,m_variable還是必須的。
回覆刪除所以說盡信書不如無書,書上所寫的建議還是要自己判斷一下。
刪除