看到這篇《How Programming Books Promote Code Smells》裡的第一條，我僅同意一半。我同意有些註解毋須存在，只要「naming」做得好即可；但是，我不同意 addBooksFromCategory 這種命名法。

該文的範例是這個樣子：

// Add Books associated with the Category
public void addBook(Category category) {
    bookMap.put(category.getCategoryId(), category.getBooks());
}

認為那行註解沒有存在的價值，因為程式改成如下即可：

public void addBooksFromCategory(Category category)
    bookMap.put(category.getCategoryId(), category.getBooks());
}

然而我認為，其實根本不必改程式，把註解拿掉即可。程式應該如下：

public void addBooks(Category category)
    bookMap.put(category.getCategoryId(), category.getBooks());
}

為什麼？因為我認為，parameters 亦為 naming 的一部份，這也是 function overloading 的價值之所在。當我們看到如下兩個函式：

public void addBooks(Book[] books);
public void addBooks(Category category);

當然可以很明確地知道，後者是「從 category 加書」，所以，其實沒有必要把函式名改成「addBooksFromCategory」。這其實跟之所以要把註解拿掉的理由一樣：去除餘冗的資訊 (remove redundant information)。

從物件導向的角度來看，method name 實為要送給 object 的 message。我認為 message 的命名最好能夠簡化，單一概念僅用單一種 message (method name) 來指涉，這樣比較易讀好懂：只有一種 addBooks 函式 (message)，比起既有 addBooks 又有 addBooksFromCategory 要來的簡單。

不過，如果今天 parameter 的意義，不是以「受詞」[1]的方式存在，那就很有必要在 method name 上動點手腳。例如這樣的寫法：

public void addBooksBy(Kiosk kiosk, Book[] books);

就比這樣的寫法好很多：

public void addBooks(Kiosk kiosk, Book[] books);

此時，kiosk 參數的「地位」，與 books 參數的地位，迥然不同。在這個情況之下，就很有必要在函式名稱裡，多加點東西，使之更「傳神」。否則，像上述後者的寫法，反而會讓人混淆，無法確定 kiosk 參數的意義與用法。

  1. 這樣的講法其實有點爭議，有空再來寫寫這部份請參見《「對象」》一文。 ↩