编程中的命名设计那点事.doc

编程中的命名设计那点事在我开始设计系统的时候，我会花去很多时间去设计命名，因为好的命名和好的设计是分不开的。In the beginning was the Word, and the Word was with God, and the Word was God太初有道。道与神同在，道就是神。 (约翰福音第一章，第一节)在设计过程中给类，方法和函数好的命名会带来好的设计，虽然这不是一定成立，但是如果坏的命名那一定不会给你带来好的设计。在设计过程，如果你发现你很难命名某一个模块，某个方法时，可能你真正遇到的问题不是难命名的问题，而是这个设计是否真的合理，你或许应该花更多的时间来重新设计一下你的模块。好的命名不仅会带来好的设计，好的命名还提高了程序的可读性，降低代码维护的成本。另一方面，如果糟糕的命名会给代码带来一堵无形的墙，让你必须深入代码去研究代码具有的行为，增加你理解代码的时间。为此我总结了几条关于命名的指导原则，希望这几条原则能为你的命名设计带来帮助，我使用的是C+的语法，当然这些原则也很容易扩展到其他语言中去。类型命名(类，接口，和结构)名字应该尽量采用名词Bad:HappyGood:Happiness不要使用类似名字空间的前缀Bad:SystemOnlineMessageGood:System:Online:Message形容词不要用太多，能描述清楚就行Bad:IAbstractFactoryPatternBaseGood:IFactory在类型中不要使用Manager 或则 Helper 或则其他没意义的单词如果你一定要在一个类型上加上Manager或Helper，那么这个类型要么就是命名的非常糟糕，要么就是设计的非常糟糕，如果是后则，那么这个类型就应该管理manage和帮助help一下自己了。Bad:ConnectionManagerXmlHelperGood:ConnectionXmlDocument, XmlNode, etc.如果某个类不能通过简单的命名来描述它具有的功能，可以考虑用类比的方式来命名Bad:IncomingMessageQueueCharacterArraySpatialOrganizerGood:MailboxStringMap如果你使用类比，你就应该一致的使用它们Bad:Mailbox,DestinationIDGood: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.VerifyAddressAndSendSt