编程中的命名设计那点事
2014-05-14 09:46
169 查看
转自:http://coolshell.cn/articles/990.html
在设计过程中给类,方法和函数好的命名会带来好的设计,虽然这不是一定成立,但是如果坏的命名那一定不会给你带来好的设计。在设计过程,如果你发现 你很难命名某一个模块,某个方法时,可能你真正遇到的问题不是难命名的问题,而是这个设计是否真的合理,你或许应该花更多的时间来重新设计一下你的模块。
好的命名不仅会带来好的设计,好的命名还提高了程序的可读性,降低代码维护的成本。另一方面,如果糟糕的命名会给代码带来一堵无形的墙,让你必须深入代码去研究代码具有的行为,增加你理解代码的时间。
为此我总结了几条关于命名的指导原则,希望这几条原则能为你的命名设计带来帮助,我使用的是C++的语法,当然这些原则也很容易扩展到其他语言中去。
不要使用类似名字空间的前缀
形容词不要用太多,能描述清楚就行
在类型中不要使用Manager 或则 Helper 或则其他没意义的单词
如果你一定要在一个类型上加上Manager或Helper,那么这个类型要么就是命名的非常糟糕,要么就是设计的非常糟糕,如果是后则,那么这个类型就应该管理manage和帮助help一下自己了。
如果某个类不能通过简单的命名来描述它具有的功能,可以考虑用类比的方式来命名
如果你使用类比,你就应该一致的使用它们
不要太简洁
避免缩写
对于完成某件事情的函数使用动词
对于返回布尔型的函数,使用类似提问的方式
对于只是返回属性,而不改变状态的函数则使用名词
不要在函数名字中重复参数的名称
不要方法的名字中重复此方法的类的名称
不要在函数的名字中加入返回类型,除非函数名必须以返回类型进行区别
不要名字中使用And 或则 Or
如果你使用一个连接词来连接函数名,那么这个函数肯定是做了太多的事情,更好的做法是将其分成更小的函数来处理(类似面向对象设计准则中的责任单一原则)。
如果你想确保是这是一个原子的操作,那么你应该用一个名字来描述这个操作或一个类来封装他
在设计过程中给类,方法和函数好的命名会带来好的设计,虽然这不是一定成立,但是如果坏的命名那一定不会给你带来好的设计。在设计过程,如果你发现 你很难命名某一个模块,某个方法时,可能你真正遇到的问题不是难命名的问题,而是这个设计是否真的合理,你或许应该花更多的时间来重新设计一下你的模块。
好的命名不仅会带来好的设计,好的命名还提高了程序的可读性,降低代码维护的成本。另一方面,如果糟糕的命名会给代码带来一堵无形的墙,让你必须深入代码去研究代码具有的行为,增加你理解代码的时间。
为此我总结了几条关于命名的指导原则,希望这几条原则能为你的命名设计带来帮助,我使用的是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();