有没有最好的方法来应对命名时尚？
去年，在我团队代码库的一些工作中，我注意到命名约定的稳步发展。
例如，有很多类的命名是为了表达它们是帮助你做某事的类。
以下是我发现的：
MyClassUtil
MyClassFactory
MyClassHelper
MyClassManager
MyClassService
在我看来，随着时间的推移，人们对相对相同的事物提出了命名约定，因此，您最终得到的代码库不是以一致的方式命名的，而是包含一些内容的代码库。每一次大会。 所有新东西都是根据最新流行的命名约定来命名的，因此您几乎可以通过当时流行的约定来判断一段代码的年龄。
应对这种趋势的最佳方法是什么？ 真的有问题吗？ 随着这些命名时尚的流行，人们应该使用最新的时尚吗？ 是否应该使用新的命名约定重命名所有现有项目？ 还是应该将多样性视为不可避免的事情来接受？
In the last year and a bit of working on my team's code base I have noticed a steady progression of naming conventions.
For example, there are a lot of classes that are named to express that they are a class that helps you do something.
Here's the ones I've spotted:
MyClassUtil
MyClassFactory
MyClassHelper
MyClassManager
MyClassService
It just seems to me that over time people come up with naming conventions for relatively the same thing and so instead of having everything named in a consistent manner you wind up with a code base that has a bit of every convention. All the new stuff is named based on the latest fad naming convention and so you can pretty much tell the age of a bit of code by what convention was in fashion at the time.
What is the best way to deal with this tendency? Is it really a problem? As these naming fads come into vogue, should one use the latest fad? Should one rename all existing items with the new naming convention? Or should one just accept the variety as something that is inescapable?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（7）
它们看起来并不像时尚……所有这些名称都暗示了该课程的目的，而这些目的是不同的。 对于编程来说，一切都在名称中，并且应该非常仔细地选择它们。 品种不需要转义。 由于类的目的不同，名称也不同。
MyClassUtil
-一些用于使用 MyClass 的实用程序，但它没有附带。 也许 MyClass 属于您正在使用的库，但您经常使用一些更高级别的函数，并且您需要某个地方来放置它们。
我的类工厂
- 以抽象的方式创建 MyClass 的实例。 这允许您编写需要 MyClass 实例的代码。 它可以从 MyClassFactory 获取这些新实例。 这将允许工厂在未来进行修改以提供 MyClass 的不同特定实现。 也许在单元测试下，工厂只提供虚拟/模拟 MyClass。 这意味着使用工厂的类可以在不需要更改的情况下进行测试，只需更改工厂，然后就可以隔离正在测试的类。
MyClassHelper
-好吧，我可能同意，也许这可以更具体。 它对 MyClass 有所帮助，但是什么呢？ 也许这和MyClassUtil有点相似。 但是，MyClassUtil 可能是与 MyClass 一起使用的通用函数，而助手则使用 MyClass 的特定实例进行初始化，然后可以对该实例进行操作。 对于您想要帮助的每个 MyClass，您都需要一个新的帮手。
我的班级管理器
-也许这涉及 MyClass 实例池并存储或编排它们。 例如。 在 CommunicationsManager 中，该类将处理连接在一起的类，这些类处理与端口或连接（如以太网或串行）的通信，以及一个处理通过其发送的通信协议的类，以便它可以传输数据包，以及一个处理通信协议的类。这些数据包中的消息。
我的班级服务
- 服务可以为您做一些事情，例如将给定的邮政编码将其转换为网格引用。 通常，服务可以解决许多特定的事情。 对于邮政编码示例，此类可能具有可以与不同网站通信以进行转换的实现。
They don't seem like fads... all these names hint at the purpose of the class, and those purposes are different. With programming, it's all in the name, and they should be chosen very carefully. The variety doesn't need to be escaped. The names vary because the purposes of the classes vary.
MyClassUtil
-Some utilities for working with MyClass that it didn't come with. Maybe MyClass belongs to a library you're using, but you often use some higher level functions with it and you need somewhere to put them.
MyClassFactory
-Creates instances of MyClass in an abstracted way. This allows you to write code that needs MyClass instances. It can get those new instances from a MyClassFactory. This would allow the Factory to modified in future to serve up different specific implementations of MyClass. Maybe under unit testing, the Factory just serves up dummy/mock MyClasses. This means a class that uses the factory can be tested without needing to change it, just change the factory, and voilà you can isolate the class being tested.
MyClassHelper
-Ok, I may agree, perhaps this can be more specific. It does something to help with MyClass, but what. Maybe this is a bit similar to MyClassUtil. But, probably MyClassUtil is general functions that work with MyClass, whereas the helper is initialized with a specific instance of MyClass and then can do operations on that one instance. You need a new helper for each MyClass you want to help.
MyClassManager
-Maybe this deals with a pool of MyClass instances and stores or orchestrates them. Eg. in a CommunicationsManager, the class would handle wiring together classes that handle talking to a port or connection like ethernet or serial, and a class that deals with the comms protocol being sent over it so it can transport packets, and a class that deals with the messages in those packets.
MyClassService
-A service can do things for you, like given a postcode convert it into a grid-reference. Usually a service can resolve to many specific things. With the postcode example, this class might be have implementations that can talk to different web sites to do the conversion.
您上面给出的所有类的名称都表明与面向对象原则的显着背离。 没有办法知道“MyClassUtil”或“MyClassService”的作用。 它可以是任何东西。 类的命名应该具体，并且应该清楚地传达类的实际功能。 这些都没有。 应对这种趋势的最佳方法是温习面向对象的编程技能并相应地命名类。
现在，这些示例可能指出了应用程序体系结构中这些类所代表的功能，并且您使用的“MyClass”只是运行时更明确的内容的占位符，在这种情况下，我不会查看这些只是命名时尚，而是类本身功能的描述性指示符，并带有应用程序底层架构的松散提示。
All of the names of classes you've given above indicate to me a striking departure from object-oriented principles. There's no way of telling what "MyClassUtil" or "MyClassService" does. It could be anything. Class naming should be specific, and should relay clearly the actual function of the class. None of these do. The best way to deal with this tendency is to brush up on object oriented programming skills and name the classes accordingly.
Now, it could be that these examples point out the function, within the application architecture, that these classes represent, and your use of "MyClass" is simply a placeholder for something more definitive at runtime, in which case, I wouldn't view these as naming fads, but rather as descriptive indicators of the function of the class itself, with a loose hint of the application's underlying architecture.
如果这种情况普遍存在，团队需要花一些时间研究 OO 设计：阅读备受推崇的 OO 框架的源代码、设计模式书籍或 Evans“领域驱动设计”等书籍。
“Util”和“Manager”通常是糟糕设计的症状——“代码味道”。 “Helper”在特殊环境（Rails 应用程序）之外也是如此，它根深蒂固。
“Factory”和“Service”都有精确的技术含义，你可以检查一下代码，看看它是否符合那些设计模式。
一般的补救措施是与团队坐下来，明确讨论您期望从这些命名方案中获得什么好处，什么有意义，什么没有意义，然后在接下来的几个月中应用重构技术来逐步淘汰你们所决定的名字都是代码味道。
命名很重要。 这不应该掉以轻心，也不是一个主观问题。 确实，对于给定的命名问题通常有多个正确答案。 然而，很少有答案与之前的选择一致，这是关键。
If this is pervasive, the team needs to spend some time studying OO design: reading the source code to well-respected OO frameworks, books on design patterns or books such as Evans "Domain Driven Design".
"Util" and "Manager" are often symptoms of poor design - "code smells". So is "Helper" outside of special contexts (Rails apps) where it's well entrenched.
"Factory" and "Service" have precise technical meanings, you can check the code to see if it conforms to those design patterns.
The general remedy is to sit down with the team, and have an explicit discussion about what benefits you're expecting from these naming schemes, what makes sense and what doesn't, and then over the next few months apply refactoring techniques to phase out the names you've all decided are code smells.
Naming is important. It shouldn't be taken lightly, nor is it a subjective matter. True, there is often more than one correct answer to a given naming issue. However, there are seldom many answers consistent with previous choices, which is key.
将名称重命名为更好的名称并重构代码，以便每个类都有明确的职责，推荐。 要了解使用哪种名称，请阅读 Tim Ottinger 关于有意义的名称的文章。
当一个类只做一件事时，给它一个描述性的名称通常很容易。 诸如“经理”之类的词是模糊的，可能表明该类负责做许多不相关的事情，以至于没有简单的名称能够描述该类所做的事情。 如果只看类名就能知道这个类是做什么的，那么这个类就有一个好名字。
Renaming the names to better ones and refactoring the code so that each class has a clear responsibility, is recommended. To know what kind of names to use, read Tim Ottinger's article about Meaningful Names.
When a class does only one thing, then giving it a descriptive name is usually easy. Words such as "manager" are vague and may indicate that the class is responsible for doing so many unrelated things, that no simple name is able to describe what the class does. If you can know what the class does just by looking at the name of the class, then the class has a good name.
我真的不明白工厂或服务如何适应特定的时尚......
工厂是一种设计模式，如果该类确实是一个工厂，那么它是一个非常合适的名称。
如果一个类是 Windows 服务，那么将其称为服务有什么问题呢？
除非您发现执行所有重命名重构的成本太高，即使您确实想要这样做，否则这不会有问题。
I don't really see how Factory or Service fit in to a particular fad...
Factory is a design pattern and if the class really is a factory then it's a perfectly appropriate name.
If a class is a Windows service what's wrong with calling it service?
There isn't a problem unless you find that performing all the rename refactors is too costly even though you really want to do them.
为什么不使用静态分析工具来帮助实施一组样式和一致性规则？
如果您身处 .NET 世界，Microsoft 提供了一个名为 StyleCop 的工具
Why not use a static analysis tool to help enforce a set of style and consistency rule?
If you're in the .NET world Microsoft provides a tool called StyleCop
在您提供的类名示例中，“MyClass”是否代表实际的类名，以便您确实看到“PersonnelRecordUtil”或“GraphNodeFactory”之类的名称？ MyClassFactory 对于类来说是一个非常糟糕的实际名称。
In the classname examples you give does "MyClass" stand for an actual class name, so that you are really seeing names like "PersonnelRecordUtil" or "GraphNodeFactory"? MyClassFactory is a really bad actual name for a class.