常数和可维护性
我有一个与良好编程实践相关的简单问题。具体来说，我很好奇处理分组常量的正确方法。在学校里，他们教我们将常量放在文件的顶部，在文件中首先声明它们（通常是班级文件，教授有一些变化）。现在，我在业界的几个地方看到，所有常量都被拉出来并卷入一个大的包含类型文件中。
在第一种情况下，提取常量是有意义的，因为这是手机游戏的代码，必须快速移植到各种令人惊叹的设备上，这提供了一个集中的工作场所。但是，后来，我发现这种重复的做法是一个完全不同的场景（公用事业的内部代码），几乎没有理由说明为什么会这样（基本上，“因为这就是他一直这样做的方式”）。
那么，最佳实践是什么？我知道这可能看起来很平常，但我总是被告知，尽早养成良好的习惯是成功的关键。
I have a simple question that relates to good programming practices. Specifically, I am curious to the proper way to handle grouping constants. In school, they taught us to place our constants at the top of the file in which they are fist declared (usually a class file and there is some variation by professor). Now, I have seen in several places in the industry in which ALL constants are pulled out and rolled into one big include-type file.
In the first case, it made sense to pull constants out as this was code for cellphone games that had to be rapidly ported to an amazing variety of devices and this provided a centralized place to work from. But, later on, I find this practice repeated is a completely different scenario (In-house code for a public utility) with little justification as to why this is so (basically, "because that is how he have always done it").
So, what would the best practices be? I know it may seem mundane, but I have always been told that starting good habits early is the key to success.
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（2）
对所有常量一视同仁通常过于简单化。每一个在其上下文中都有不同的含义，我对待它们的方式也相应地有所不同。下面是一个小表，其中列出了上下文以及我如何处理此上下文中的常量。如果您认为有更好的方法，请纠正我。
singleton或factory模式（或在 DI 框架）。其他常量有其自己的上下文。我喜欢将常量移出代码，因为无论听起来多么矛盾，常量往往会改变。
出于同样的原因，将所有常量放在一个大文件中也是不好的。假设您的一个程序集仅依赖于常量 X。即使常量 Y 更改，该程序集也必须重新编译，并且此更改应该不会影响它。
Treating all constants equally is usually an oversimplification. Each one has a different meaning in its context, and the way I treat them varies accordingly. Below is a small table of contexts vs how I handle constants in this context. Please correct me if you think there is a better approach.
enums: Enums wrap multiple constants in the same context nicely (for example, days of the week, connection state...). I usually put the definition in the same package as it's used, or in a shared library if multiple assemblies/components will use it.singletonorfactorypatterns can be applied (or register the object in a DI framework).Other constants have their own contexts. I like to move constants out of code since, however paradoxical it may sound, constants tend to change.
For the same reason, putting all constants in one big file is bad. Let's say one of your assemblies depend only on constant X. This assembly has to be recompiled even when constant Y changes, and this change should not have affected it.
为了给出一个过于简化的答案，我认为最好将它们放在您期望找到它们的地方。意思是，对它们进行分类。这涉及到内聚原则。这样做的优点是，当您需要它们时，您会更容易地找到它们。您可以轻松地仅包含所需的常量，而不会因其他未使用的常量而污染您的命名空间。
另一个重要的注意事项是，如果可能的话，将相关常量分组到枚举中。例如，对齐常量将进入枚举 Align。
To give an over simplified answer, I believe it's best to place them where you would expect to find them. Meaning, categorize them. This relates to the cohesion principle. Advantages of this are that you will find them easier when you need them. You can easily include only the constants you need, without polluting your namespace with other unused ones.
Another important note is, if possible, group related constants into enums. E.g. alignment constants would go into an enum Align.