What's the point of using constants for property keys?

Question

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.

Answer 1

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.

Answer 2

For one thing, you cannot mistype the keys when using constants without getting a compiler error.

Answer 3

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:

• A constant means typos will get compiler errors, a String wouldn't
• a constant lets you separate the key "ID" for one property file verses the key "ID" for another XML file. Same String, different meaning.
• a global search and replace could break lots of things, whereas your IDE will let you search for all usages of a constant very easily, and change only the relevant ones.

In a lot of cases, it is just a good habit that programmers got into, but good habits are there for a reason.

Answer 4

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.

Answer 5

Because autocomplete works better on identifiers for constants, but if all your key values are "com.foo.bar.whatever" you get no feedback.