使用常量作为属性键有什么意义？
最近，我遇到了很多依赖“属性文件”进行配置的 Java 代码。 但代码使用常量（静态最终字符串）来检索属性值，而不是普通的旧字符串文字。
我发现这种额外的间接级别很烦人，因为我需要在任一方向执行两次查找。 如果我从配置文件中观察到的属性开始，我必须首先搜索属性名称以查找 Java 常量，然后再次搜索以查找代码中对该常量的引用。 如果我从代码开始，我必须先找到常量的实际值，然后才能确定配置文件中属性的值！
有什么意义？
我了解使用常量来引用资源包中的键的价值，通常是为了支持 i18n。 我指的是简单的、非面向用户的配置值。 我能想到的唯一原因是为了以后可以轻松更改属性名称，但恕我直言，这种好处远远小于烦恼，特别是考虑到全局搜索和替换的便利性。
Lately, I've come across a lot of Java code that relies on "properties files" for configuration. But instead of plain old string literals, the code uses constants (static final Strings) to retrieve the property values .
I find this extra level of indirection annoying because I need to perform TWO lookups in EITHER direction. If I start with the property observed in the config file, I have to first search for the property name to find the Java constant, and then search again to find the references to the constant in the code. If I start in the code, I have to find the actual value of the constant before I can then determine the value of the property in the config file!
What's the point?
I understand the value of using constants to reference keys in a resource bundle, usually in support of i18n. I'm referring to simple, non-user-facing config values. The only reason I can think of is to make it easy to change the property name later, but this benefit is far less than the annoyance IMHO, especially given the ease of a global search and replace.
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（5）
一方面，在使用常量时，您不能输错键而不出现编译器错误。
For one thing, you cannot mistype the keys when using constants without getting a compiler error.
如果需要在不重新编译的情况下更改某个值，那么您不可避免地需要进行一些重定向，但是再进行另一个重定向是相当愚蠢的，除非需要在多个位置引用该键（这本身就是关注点分离不佳的可能迹象）。
键字符串应该具有足够的描述性，以便它们不会与范围之外的其他字符串（通常是类）发生冲突，并且保持单个类中的文字唯一既不复杂，也不可能成为值得在单个块中声明的严重问题。 因此（IMO）这种做法只是某人盲目遵守规则而不了解规则的初衷。
如果您需要向他们引用另一项指南来证明放松这一指南的合理性，我可以建议 KISS。
If a value needs to be changed without a recompile you inevitably need some redirection but doing yet another is pretty foolish unless the key needs to be referenced in more than one place (itself a possible sign of poor separation of concerns).
Key strings should be sufficiently descriptive that they cannot collide with others outside their scope (normally class) and keeping literals within a single class unique is neither complex nor likely to be so serious a concern as to merit their declaration in single block. Therefore (IMO) this practice is simply someone slavishly following rules without understanding the rule's original intent.
If you need to quote an alternate guideline to them to justify the relaxing of this one may I suggest KISS.
即使在简单的全局搜索和替换（这不是新鲜事）的今天，使用常量也可以让您知道该字符串仅适用于该属性文件。 这很好，因为：
很多时候，这只是程序员养成的一个好习惯，但好习惯的存在是有原因的。
Even in the day of easy global search and replace (which isn't a new thing) using a constant lets you know that the String is just for that property file. This is good because:
In a lot of cases, it is just a good habit that programmers got into, but good habits are there for a reason.
我以前也见过这种做法，事实上，有一次我在一个项目中，我必须搜索一个常量文件，该文件引导我找到一个 XML 文件，该文件最终会为我提供我正在寻找的属性名称。 然后我还必须查看属性文件，因为该值是我真正想要的。
我认为这是杰夫和乔尔在最后一个播客中谈论的内容的一个例子，其中开发人员盲目地遵循他们听说过的一种做法（在本例中，就是在代码中永远不要使用字符串文字的做法），而不考虑考虑到手头的问题它是否真的合适。
I've seen this practice before too, in fact once I was on a project where I had to search for a constants file which led me to an XML file which would finally give me the property name that I was looking for. And then I had to look at the property file too, since the value was what I really wanted.
I think this an example of the stuff that Jeff and Joel were talking about on the last podcasts, where developers are blindly following a practice that they've heard about (in this case, the practice to never have a string literal in your code) without thinking about whether or not it's really appropriate given the matter at hand.
因为自动完成对于常量的标识符效果更好，但如果所有键值都是“com.foo.bar.whatever”，您将得不到任何反馈。
Because autocomplete works better on identifiers for constants, but if all your key values are "com.foo.bar.whatever" you get no feedback.