由於最近上了一門有關Clean code的課程,
所以這邊就簡單地做了一下筆記避免將來忘記
我們一定要謹慎小心地命名, 避免後人維護時看得霧沙沙
以下就簡單舉例什麼是不好的命名(Poor name)一. MySterious Names
沒辦法一眼看出變數或方法用意的名字
SqlDataReader drl;
int od;
void Button1_click();
class Page1{}
|
這個例子，我們很難看出宣告drl，od， Button1_click，Page1 到底用意為何
如果將來有個Button2_click，那他跟Button1_click的差別又在哪?
我們必須去看實作細節才能知道這些變數\方法的用意
一般而言，好的名字必須滿足:
- "Clean"(不拖泥帶水)
- "Intention-Revealing"(意圖明顯)
剛剛的範例我們或許可以改成：
SqlDataReader dataReader;
int overdueDays;
void CheckAvailability_Click();
class ViewCustomerPage{}
|
二. Meaningless Names
沒意義難以理解的名字，
這對於我們去了解這方法一點幫助也沒有
void BeginCheckfunctionality_StoreClientSideCheckBoxIdsArray();
|
此時我們還是得去看實作細節才能知道這方法在幹嘛
如果方法的內容很長想必會耗費我們許多寶貴的時間
通常這種方法它可能不只做一件事情
又由於要滿足Intention-revealing並不容易，所以才會出現種名稱
如何改善：
- 盡量縮短名稱
- 盡量讓方法內的程式碼小於10行
- 盡量讓方法只做一件事情
如此的話就很容易取個meaningful name
三. Names with Encodings
使用匈牙利命名法
如:
int iMaxRequests;
|
這裡建議盡量少用匈牙利命名法
早期的C\C++程式開發者由於IDE不發達所以才衍伸出這個方法
但現在的IDE多半都很強，滑鼠移過去就可以直接看到變數值
所以我們沒有必要特別使用匈牙利命名法
以上的例子建議改成
int maxRequests;
|
我們再來看使用另一個例子
var m_objCollection = new StringCollection();
|
這裡我們替某collection用匈牙利命名法命名
但問題是我們仍然很難看出這個collection到底是用來放什麼
如果這個collection是用來存放顧客名稱
那為何不改成叫做customNames
四. Ambigous Names:
容易誤解的名字
bool MutiSelect(){}
|
以上面的例子來說，到底是想表示可以有很多選擇，還是被選了很多!?
還有，
int? customerNameId;
|
這是想表達什麼?是客戶名稱呢還是Id
如果是客戶名稱的話那為什麼資料型別是整數
如果是想表達客戶的Id的話，那為什麼可以允許Id是null
最後 Noisy Names
不必要的字
Customer theCustomer;
List<Customer> listOfApprovedCustomers;
|
去除不必要的字，讓名稱看起來簡短且易讀
// good
Customer customer;
List<Customer> approvedCustomers;
|
結論(若能滿足下列幾點就是個好名字)：
- Not too short, not too long(不要太長也不要太短)
- Meaningful(有意義)
- Reveal intention(意圖明顯)
留言
張貼留言