我正在开发一个框架，并且一些对象具有相当长的名称。我不是很喜欢这个，但我也不喜欢缩略词。我试图为“EventModelSocket”提供一个较短的名称，基本上是实现各种事件的.Net套接字类的包装器，以及发送文件，对象等的方法。由于这个，一些对象的名称很长，例如“EventModelSocketObjectReceivedEventArgs”。
我尝试了从词库到字典的所有内容，坐在这里好好思考。
当你遇到这样的情况时，最好的方法是什么？
答案 0 :(得分：20)
将其中的一部分推入命名空间。
例如：
EventModelSocketObjectReceivedEventArgs
变为
EventModel.Sockets.ReceivedEventArgs
答案 1 :(得分：10)
那么长名字会伤害什么吗？
（编辑）另外两个想法：
var - 这将节省一半的宽度如果您在文件中多次使用该类型，请考虑类型别名，如果它让您烦恼：
using Fred = Namespace.VeryLongNameThatIsBeingAnnoying;
答案 2 :(得分：9)
我建议使用描述该对象的最简洁的命名。
如果EventModelSocketObjectReceivedEventArgs执行此操作，请继续。
我的2美分。
答案 3 :(得分：4)
多年前，当我在编程课程中时，该教授引用了一个统计信息，即每次修改时，一段代码通常会被读取600次。如今，我认为这已不再适用，特别是在TDD环境中，正在进行大量的重构。尽管如此，我认为给定的代码片段仍然读取的次数比写入的次数多得多。因此，我认为我们应该为可读性而编写的格言仍然有效。名称中单词的完整形式更具可读性，因为大脑不必进行转换。理解更快，更准确。
我们今天拥有的工具可以通过自动完成等方式轻松实现。因此，我现在在变量名中使用完整的单词，我认为这是一个很好的方法。
答案 4 :(得分：2)
如果您需要花费很多精力来寻找替代名称，那么您已经拥有了正确的名称。对象/方法/属性名称应该是自我记录的。如果他们没有描述他们的确切目的，他们就会被误称。如果长名称能够最清楚地理解该对象的用途，那就没有错。
在这个智能感知和大型监视器的时代，没有理由在命名时没有尽可能具有描述性。
答案 5 :(得分：2)
不要删除元音或类似的东西。
我和“坚持长名”的人在一起。
有一种想法是，如果名称那么尴尬，可能需要对系统进行更深入的重新思考。
答案 6 :(得分：1)
我用一个长名字。使用intellisense输入名称并不重要，除非您使用的是15英寸显示器。
如果我不得不减少名字，我可能会使用EvtMdlSck，只是让工作更短但仍然可以理解。即使这不是我的偏好。
答案 7 :(得分：1)
对你的命名有些批评......
为什么你的组件名称中包含“模型”一词 - 不是有点多余。
由于您的组件似乎是某种消息传递中心，为什么不包含它 消息名称。那么MessageSender呢？
要解决您的问题，我会创建一个接口并为其指定一个通用名称 MessageSender和一个实现，您可以在其中包含名称中的技术，如RandomFailingSocketMessageSender。
如果有人希望得到一个很好的例子，请看一下Java或.Net库..
来自Java。 接口 - 类/实现...... Map - HashMap，LinkedHashMap。 列表 - LinkedList
有关所使用的技术或框架的详细信息，例如像“Socket”这样的词，或者可能使用一个人为的例子“MQSeries”，根本不应该是接口名称的一部分。
MessageSender似乎恕我直言总结了你的组件的目的。发送“文件”和“事件”的东西不包括这两个描述性词语，这似乎很奇怪。你在命名中使用的东西是多余的，恕我直言不符合你对组件的描述。
答案 8 :(得分：0)
一般来说，我相信准确描述其功能的类名，而且可以使用长名称。如果你认为这些名字确实变得越来越长，我建议你找一个你的编程团队所熟知的概念并简化它。因此，如果“事件模型套接字”是每个人都知道的概念，那么将它们缩写为EMS。如果你有一个完全与Event Model Sockets有关的软件包，那么在该软件包内部的所有类中将它们缩写为EMS。他们关键在于确保任何可能不熟悉这个概念并且缩写为任何人的名字都是完整的。