我已经尝试使用同义词词典和字典,还花了几小时思考,但都没找到好的解决办法。
当你遇到这样的情况时,最好的方式是如何命名呢?
将其中一些内容推入命名空间中。
例如:
EventModelSocketObjectReceivedEventArgs
变成
EventModel.Sockets.ReceivedEventArgs
那么,长名称是否会影响什么呢?
(编辑) 另外两个想法:
var
- 这将节省一半的宽度如果您在文件中多次使用该类型,请考虑使用类型别名来避免烦恼:
using Fred = Namespace.VeryLongNameThatIsBeingAnnoying;
我建议使用最简洁的命名来描述对象。如果EventModelSocketObjectReceivedEventArgs
做到了这一点,那就可以继续使用了。以上是我的个人意见。
不要删除元音或类似的奇怪行为。
我赞同“坚持使用长名称”的人的观点。
一个想法是,如果名称如此尴尬,可能需要对系统进行更深入的重新思考。
我个人使用完整的名称。在智能感知中,打出名称并不重要,除非您使用的是15英寸的显示器。
如果我必须缩短名称,我可能会选择EvtMdlSck,以使工作更加简短但仍然易于理解。尽管那不是我的首选。
对你的命名提出一些批评...
为什么你的组件名中包含了"model"这个词-这不是有点多余吗。
由于你的组件似乎是某种消息枢纽,为什么不在名称中包括 Message 呢?MessageSender 怎么样?
为了解决你的问题,我会创建一个接口并给它一个通用的名称,比如 MessageSender,实现时,你可以在其中包含技术,例如 RandomFailingSocketMessageSender。
如果想要一个很好的范例,请看 Java 或 .Net 库...
Java 中的举例: 接口-类/实现... Map - HashMap、LinkedHashMap。 List - LinkedList。
关于使用的技术或框架的详细信息,比如像 "Socket" 这样的单词,或者也许使用一个牵强的例子,"MQSeries",都不应该成为接口名称的一部分。
MessageSender 似乎总结了你的组件的目的。奇怪的是,你的发送 "文件" 和 "事件" 的东西没有包括这两个描述性的词。你在命名中使用的东西是多余的,并且在我看来不符合你对组件的描述。