在我開始設計系統的時候，我會花去很多時間去設計命名，因爲好的命名和好的設計是分不開的。
In the beginning was the Word, and the Word was with God, and the Word was God
太初有道。道與神同在，道就是神。 (約翰福音第一章，第一節)
在設計過程中給類，方法和函數好的命名會帶來好的設計，雖然這不是一定成立，但是如果壞的命名那一定不會給你帶來好的設計。在設計過程，如果你發現你很難命名某一個模塊，某個方法時，可能你真正遇到的問題不是難命名的問題，而是這個設計是否真的合理，你或許應該花更多的時間來重新設計一下你的模塊。
好的命名不僅會帶來好的設計，好的命名還提高了程序的可讀性，降低代碼維護的成本。另一方面，如果糟糕的命名會給代碼帶來一堵無形的牆，讓你必須深入代碼去研究代碼具有的行爲，增加你理解代碼的時間。
爲此我總結了幾條關於命名的指導原則，希望這幾條原則能爲你的命名設計帶來幫助，我使用的是C++的語法，當然這些原則也很容易擴展到其他語言中去。
類型命名(類，接口，和結構)
名字應該儘量採用名詞Bad: Happy
Good: Happiness
不要使用類似名字空間的前綴Bad: SystemOnlineMessage
Good: System::Online:Message
形容詞不要用太多，能描述清楚就行Bad: IAbstractFactoryPatternBase
Good: IFactory
在類型中不要使用Manager 或則 Helper 或則其他沒意義的單詞
如果你一定要在一個類型上加上Manager或Helper，那麼這個類型要麼就是命名的非常糟糕，要麼就是設計的非常糟糕，如果是後則，那麼這個類型就應該管理manage和幫助help一下自己了。Bad: ConnectionManager
XmlHelper
Good: Connection
XmlDocument, XmlNode, etc.
如果某個類不能通過簡單的命名來描述它具有的功能，可以考慮用類比的方式來命名
Bad: IncomingMessageQueue
CharacterArray
SpatialOrganizer
Good: Mailbox
String
Map
如果你使用類比，你就應該一致的使用它們Bad: Mailbox,DestinationID
Good: Mailbox,Address
函數(方法和過程)
簡潔Bad: list.GetNumberOfItems()
Good: list.Count()
不要太簡潔Bad: list.Verify()
Good: list.ContainsNull()
避免縮寫Bad: list.Srt()
Good: list.Sort()
對於完成某件事情的函數使用動詞Bad: obj.RefCount();
Good: list.Clear();
list.Sort();
obj.AddReference();
對於返回布爾型的函數，使用類似提問的方式Bad: list.Empty();
Good: list.IsEmpty();
list.Contains(item);
對於只是返回屬性，而不改變狀態的函數則使用名詞Bad: list.GetCount();
Good: list.Count();
不要在函數名字中重複參數的名稱Bad: list.AddItem(item);
handler.ReceiveMessage(msg);
Good: list.Add(item);
handler.Receive(msg);
不要方法的名字中重複此方法的類的名稱Bad: list.AddToList(item);
Good: list.Add(item);
不要在函數的名字中加入返回類型，除非函數名必須以返回類型進行區別Bad: list.GetCountInt();
Good: list.GetCount();
message.GetIntValue();
message.GetFloatValue();
不要名字中使用And 或則 Or
如果你使用一個連接詞來連接函數名，那麼這個函數肯定是做了太多的事情，更好的做法是將其分成更小的函數來處理(類似面向對象設計準則中的責任單一原則)。
如果你想確保是這是一個原子的操作，那麼你應該用一個名字來描述這個操作或一個類來封裝他Bad: mail.VerifyAddressAndSendStatus();
Good: mail.VerifyAddress();
mail.SendStatus();
文章出處： 酷 殼 – CoolShell.cn