类型的缩短命名规则

8
我正在开发一个框架,其中一些对象的名称非常长。我不太喜欢这样,但我也不喜欢缩写。我正在尝试为“EventModelSocket”寻找更短的名称,它基本上是.Net socket类的包装器,实现了各种事件和发送文件、对象等方法。由于这个原因,一些对象的名称非常长,例如“EventModelSocketObjectReceivedEventArgs”。
我已经尝试使用同义词词典和字典,还花了几小时思考,但都没找到好的解决办法。
当你遇到这样的情况时,最好的方式是如何命名呢?
9个回答

20

将其中一些内容推入命名空间中。

例如:

EventModelSocketObjectReceivedEventArgs

变成

EventModel.Sockets.ReceivedEventArgs

@Longhorn213 ReceivedEventArgs在框架命名空间中没有任何冲突 - 使用using语句有什么问题吗?此外,它解决了David Anderson遇到的真正问题(请参见另一个答案的评论),即在解决方案资源管理器中导航。 - Randolpho
这个组件的标识符仍然非常长。它并没有真正解决问题 - 这个类的名称告诉我它是做什么还是它持有什么值? - mP.
@Jay Bazuzi-我打算建立一个框架,用于我们未来的产品,因此它已经有了非常有组织的结构。例如BitFlex.IO、BitFlex.Windows.Forms等。他的建议很好,因为我已经有了BitFlex.Net.Sockets和一个100% FxCop通过的库 :) - David Anderson
如果我需要多个'ReceivedEventArgs'对象,我会在需要时处理它:P - David Anderson
哇...当我写这个的时候,我觉得它很平凡。我不知道它会引起争议。到目前为止,这个答案已经有3个踩了...这是我第二个被踩最多的答案。 - John MacIntyre
显示剩余8条评论

10

那么,长名称是否会影响什么呢?

(编辑) 另外两个想法:

  • 在C# 3.0中使用var- 这将节省一半的宽度
  • 如果您在文件中多次使用该类型,请考虑使用类型别名来避免烦恼:

    using Fred = Namespace.VeryLongNameThatIsBeingAnnoying;


在SolutionExplorer中有很多源文件,如果能够快速浏览并找到所需的文件而不必调整大小并阅读一长串的名称列表,那么工作效率会更高。与此单个对象相关的源文件相当多,最好采用另一个名称。 - David Anderson

9

我建议使用最简洁的命名来描述对象。如果EventModelSocketObjectReceivedEventArgs做到了这一点,那就可以继续使用了。以上是我的个人意见。


4
多年前我上编程课时,教授引用了这样一项统计数据:每当代码被修改一次,通常会有600次阅读。如今,在TDD环境下进行大量重构的情况下,我认为这个说法已经不再适用。然而,我认为一个给定的代码片段被阅读的次数仍然比它被编写的次数多得多。因此,我认为我们应该以可读性为重点来编写代码。在名称中使用单词的全拼更容易读懂,因为大脑无需转换。理解速度更快,准确性更高。
现在我们拥有自动完成等工具,使这变得非常容易。因此,我现在在变量名称中使用全名,并且我认为这是一个好方法。

2
如果你需要花费这么多的精力去寻找一个替代名称,那么你已经有了正确的名称。对象/方法/属性的名称应该是自我说明的。如果它们不能描述其确切的目的,那么它们就被命名错误了。如果长名称能够最清晰地表达该对象的目的,那么它们并没有什么问题。
在这个智能感知和大屏幕的时代,没有理由不尽可能地详细地命名。

2

不要删除元音或类似的奇怪行为。

我赞同“坚持使用长名称”的人的观点。

一个想法是,如果名称如此尴尬,可能需要对系统进行更深入的重新思考。


1

我个人使用完整的名称。在智能感知中,打出名称并不重要,除非您使用的是15英寸的显示器。

如果我必须缩短名称,我可能会选择EvtMdlSck,以使工作更加简短但仍然易于理解。尽管那不是我的首选。


1

对你的命名提出一些批评...

为什么你的组件名中包含了"model"这个词-这不是有点多余吗。

由于你的组件似乎是某种消息枢纽,为什么不在名称中包括 Message 呢?MessageSender 怎么样?

为了解决你的问题,我会创建一个接口并给它一个通用的名称,比如 MessageSender,实现时,你可以在其中包含技术,例如 RandomFailingSocketMessageSender。

如果想要一个很好的范例,请看 Java 或 .Net 库...

Java 中的举例: 接口-类/实现... Map - HashMap、LinkedHashMap。 List - LinkedList。

关于使用的技术或框架的详细信息,比如像 "Socket" 这样的单词,或者也许使用一个牵强的例子,"MQSeries",都不应该成为接口名称的一部分。

MessageSender 似乎总结了你的组件的目的。奇怪的是,你的发送 "文件" 和 "事件" 的东西没有包括这两个描述性的词。你在命名中使用的东西是多余的,并且在我看来不符合你对组件的描述。


这只是一个套接字包装器,它消除了编写发送和接收文件、大数据、对象等代码的需要,并且无需编写事件来显示发送/接收操作的进度。它实现了自己的“类HTTP”协议,但本质上只是一个自定义套接字 :) - David Anderson
我通常也不喜欢在类名中使用“model”这个词,但如果套接字专门用于传递事件模型,则这是正确的名称。 - DJClayworth
接口名称应该简短而简单,尽量避免提及具体的技术。这是在Java或.NET中常见的一种模式。 - mP.

0
一般来说,我认为类名应该准确地描述它们的功能,并且使用长名称是可以接受的。如果你觉得名称变得太长了,我的建议是找到一个编程团队都熟知的概念并对其进行缩写。例如,如果“事件模型套接字”是一个所有人都知道的概念,那么可以将其缩写为EMS。如果你有一个完全关于事件模型套接字的包,那么在该包内部的所有类中都可以将其缩写为EMS。关键在于确保对于可能不熟悉该概念的人来说,名称是完整的;而对于熟悉该概念的人来说,则可以进行缩写。

网页内容由stack overflow 提供, 点击上面的
可以查看英文原文,
原文链接