關鍵點

　　“別人還能把這個名字理解成什么意思？”通過不斷的問自己這個問題來積極檢查每一個命名。

　　事實上，這種富有創造性的、不斷嘗試“錯誤理解”的方法，能夠有效的發現歧義的命名，并修正它們。正如本文中的示例，我們將隨時通過“騎驢看唱本 ——邊走邊瞧”的方式來探討所見到名字的誤解之處，然后選取一個更好的名字。

　　示例：Filter()

　　假設寫了一段代碼來操作數據庫結果的集合：

results = Database.all_objects.filter("year <= 2011")

　　那么，results包含什么數據呢？

• 所有滿足year<=2011的對象
• 所有不滿足year<=2011的對象

　　問題的由來是從filter這個有歧義的詞開始的，它沒有清楚表達它的意思是“選取”還是“剔除”。因此，應該避免使用filter，它太容易造成誤解！

　　如果這里想要的效果是“選取”，一個更好的名字是select；如果想要的是“剔除”，更好的名字則是exclude。

　　為布爾值取名

　　當為布爾值變量命名或者函數返回布爾值的時候，要特別注意真和假所表達出來的真實意思，這里就有一個很危險的例子：

bool read_password = true;

　　這句代碼意思取決于當時怎么閱讀的（沒有其他的意思了），顯然這里有兩種截然不同的理解：

• 需要讀密碼
• 密碼已經被讀過了

　　在這個用例下，做好避免用單詞read，可以考慮使用need_password或者user_is_authenticated來代替。

　　通常情況下，添加單詞is、has、can或者should可以讓布爾值的意思更加清晰易懂。

　　比如說有個函數叫SpaceLeft()，乍一看，就會想到這個函數返回的值是數字。如果需要明確返回值是布爾值，一個更好的名字是 HasSpaceLeft()。

　　還有，盡量避免使用反義短句來命名。例如：

bool disable_ssl = false;

　　改成如下代碼則更容易理解，同時更契合原意：

bool use_ssl = true;

　　符合用戶期望

　　很多名字是帶有誤導性的，因為對于某個名字，用戶自已有一個預想的定義，但是代碼的意思可能恰恰不是這個意思。如此情況下，最好作出“讓步”并改變名字，消除誤導性。 

　　示例：get*()

　　許多程序員都在使用這樣的編碼規范：某個方法以get開頭來表達一個“輕量級的訪問器”以返回內部成員。違反這個規范將很容易誤導用戶。 避免下面的例子中Java代碼段的做法：

public class StatisticsCollector {
    public void addSample(double x) { ... }
    public double getMean() {
    // Iterate through all samples and return total / num_samples
    }
    ...
}

　　這里，getMean的實現是枚舉過去所有的數據，并計算其平均值。如果數據量很大的時候，這一步的開銷將會是非常大的。但是，一個不了解情況的程序員則會很粗心的調用它并且假設這是一個很廉價的調用。
　　因此，這個方法應該改名成類似computeMean()這樣的，看起來這樣就是一個代價高昂的操作了（或者，另一個選擇就是改寫其實現，變成一個名副其實的輕量級操作）。

　　示例：list::size()

　　這里講一個C++標準庫里的命名問題。這段代碼導致的結果是，很難定位和修復類似導致服務器龜速運行之類的問題：

void ShrinkList(list<Node>& list, int max_size) {
    while (list.size() > max_size) {
        FreeNode(list.back());
        list.pop_back();
    }
}

　　這樣的bug的導致是作者沒有意識到list.size()是一個O(n)復雜度的操作——它挨個計數鏈表的節點得出總數而不是返回已計算好的總個數，這將導致ShrintList是一個O(n2) 的操作。

　　從技術角度講，這段代碼沒有問題，也能通過所有的單元測試。但是當調用ShrintList()并傳入一個包含上億數量級的list時，它可能將耗費數小時的時間。

　　或許你會認為，這個是調用者的錯誤使用，他/她沒有認真仔細的閱讀相關的文檔！確實是這樣的，但是，事實上，這里的list.size()不是一個恒準時（constant-time）操作，這太意外了！其他所有的C++容器類都是恒準時的size()方法呀。

　　假如把size()更名成countSize()或者countElements()，類似的錯誤就會大大減少了。C++標準庫的實現者可能想的是使用一個size()方法去和其他的容器匹配，像vector和map，這樣API的一致性看起來更好。正是由于這樣的做了，導致程序員容易誤用并認為這是一個很快的操作，和其他的容器一樣！幸運的是，最新的C++標準要求size()是O(1)復雜度。