最近，我遇到了很多依赖“属性文件”进行配置的 Java 代码。但是代码使用常量（静态最终字符串）来检索属性值，而不是普通的旧字符串文字。
我发现这种额外的间接级别很烦人，因为我需要在任一方向执行两次查找。如果我从配置文件中观察到的属性开始，我必须先搜索属性名称以找到 Java 常量，然后再次搜索以找到代码中对该常量的引用。如果我从代码开始，我必须先找到常量的实际值，然后才能确定配置文件中属性的值！
重点是什么？
我理解使用常量来引用资源包中的键的价值，通常是为了支持 i18n。我指的是简单的、非面向用户的配置值。我能想到的唯一原因是以后可以轻松更改属性名称，但是这种好处远不及恕我直言的烦恼，尤其是考虑到全局搜索和替换的简便性。
一方面，您不能在使用常量时错误地键入键而不会出现编译器错误。
即使在简单的全局搜索和替换（这不是新事物）的日子里，使用常量也可以让您知道 String 仅用于该属性文件。这很好，因为：
在很多情况下，程序员养成的习惯只是一个好习惯，但好习惯的存在是有原因的。
如果需要在不重新编译的情况下更改值，则不可避免地需要进行一些重定向，但是再做另一个是非常愚蠢的，除非需要在多个地方引用键（这本身可能是关注点分离不佳的标志）。
关键字符串应该具有足够的描述性，以至于它们不能与超出其范围（通常是类）的其他内容发生冲突，并且在单个类中保持唯一的文字既不复杂，也不可能成为值得在单个块中声明的严重问题。因此（IMO）这种做法只是在不了解规则的初衷的情况下盲目遵守规则的人。
如果您需要向他们引用替代指南来证明放松这一点的合理性，我建议您使用 KISS。
我以前也见过这种做法，事实上，有一次我在一个项目中必须搜索一个常量文件，这导致我找到一个 XML 文件，该文件最终会给出我正在寻找的属性名称。然后我也必须查看属性文件，因为值是我真正想要的。
我认为这是 Jeff 和 Joel在上次播客中谈论的内容的一个示例，开发人员盲目地遵循他们听说过的做法（在这种情况下，在代码中永远不要使用字符串文字的做法）没有考虑考虑到手头的事情是否真的合适。
因为自动完成在常量标识符上效果更好，但是如果您所有的键值都是“com.foo.bar.whatever”，您将得不到任何反馈。