你如何维护你的程序词汇？
在一个不太小的程序中，当你有不少实体时，为了保持代码的可读性、通用术语以及提高团队成员之间的相互理解，必须定义和维护程序词汇表< /强>。
您（或您的公司）如何处理这项任务，您有什么纪律，您采取什么安排？
In a not-so-small program, when you have not-so-few entities, in order to maintain code readability, common terms, and otherwise improve mutual understanding between team members, one have to define and maintain program vocabulary.
How do you (or your company) deal with this task, what discipline do you have, what arrangements do you introduce?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（5）
领域驱动设计在这里很有趣，因为它鼓励程序员接受领域词汇。 最重要的是，有一些设计约定，允许您使用众所周知的术语（例如服务、存储库、工厂等）引用应用程序的某些部分。
结合领域词汇并使用上面的技术约定可能是一个很好的解决方案。
Domain Driven Design is interesting here, since it encourages programmers to embrace the domain vocabulary. On top of that, there is some design conventions, which allow you to refer parts of your application using well known terms, like services, repositories, factories, etc.
Combining domain vocabulary and using technical conventions above it could be a good solution.
我的团队将此类信息（约定/词汇等）保存在维基百科上。 这使得您可以轻松地了解最新情况并进行共享。
My team keeps this kind of information (conventions/vocabulary etc.) on a wiki. This makes it easy to keep up to date and share.
将您的包/模块划分为逻辑组，并使用描述性和简洁的名称。 避免使用通用名称，除非它们确实是计数器等。为函数或功能组创建约定并遵守它们。
Divide your packages/modules into logical groups and use descriptive and concise names. Avoid generic names except if they are really counters etc. Create conventions for groups of functions or functionality and stick to them.
大多数规模合理的项目都应该有一个编程/编码标准文档，规定应遵循的通用约定和命名指南。
另一种帮助解决此问题的方法是通过代码审查。 显然，审阅者之间需要进行一些协调（该文件也对此有所帮助）。 代码审查有助于让绿色开发人员和高级开发人员保持在正轨上，并充当执行编码标准的途径。
Most projects of reasonable size should have a programming/coding standards document that dictates common conventions and naming guidelines that should be followed.
Another way to help with this is through code reviews. Obviously some coordination among reviewers is required (the document helps with that, too). Code reviews help keep the greener devs and senior devs alike on track and act as an avenue to enforce the coding standards.
@Ilya Ryzhenkov，
恐怕大多数公司都没有这样的做法:)我曾在一家拥有数百万 LOC 代码库的不那么小的公司工作过，他们根本没有任何文档（除了通用编码指南） ）
在我的一个项目中，我们维护了应用程序领域中使用的常用术语的同义词库，并在代码审查期间使用它。 我时常分析 .NET XML 文档差异，以决定应将哪些实体\术语添加到同义词库中。 强制遵守同义词库的唯一方法是编码指南。
事实证明 Wiki 方法不适用，因为没有人愿意定期更新它:)
我想知道您在 JetBrains 使用什么方法？ 我在 Reflector 中检查了 ReSharper 的代码，并对实体的数量和名称感到惊讶:)
@Ilya Ryzhenkov,
I'm afraid most companies don't have such practice :) I've worked in the not-so-small company with multimillion LOC code base and they don't have any documentation at all (beside common coding guideline)
On one of my projects we maintained thesaurus of common terms used in our application domain and used it during code review. I analyzed .NET XML documentation diff from time to time to decide which entities\terms should be added to the thesaurus. Only means to enforce compliance with thesaurus was coding guideline.
Wiki approach proved to be non-applicable because nobody cares to update it regularly :)
I'm wondering what methods do you use at JetBrains ? I've inspected ReSharper's code in Reflector and was amazed with number and names of entities :)