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.
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.