String Constants

21 September, 2006. 638 words.

Another in a series of random programming tips by Thomas Krehbiel, mostly to help me remember them in the future.

I don’t know about anyone else, but I hate working with code where all the strings are defined as constants at the top of the file. You know, things like error messages or table names. It makes it virtually impossible to glance at the code and see what’s going on. You have to keep scrolling up and down in the file to figure out what the error messages, dialog strings, etc. are. Not only that, but you have to do two searches in the code to find where a particular error message occurs: First you have to find the error message, then you have to find where the string constant is used.

I figure people might write code like this for two reasons: 1) They want to prepare for globalizing their software, or 2) They want to put all the strings at the top of the file so non-programmers can mess with the code without breaking it. They might also do it for a third reason: Because somebody told them to.

I can understand that there might be a need for globalization of software. In that case, you obviously can’t embed strings directly in your code. But let’s look at these simple examples from recent projects I’ve worked on:

public const string COL_ESTIMATED_VALUE = "estimated_value";

If it isn’t obvious, this is a string constant for a database column name. To my way of thinking, you’d (ironically) use constants for things you thought might be changed in the future, so you wouldn’t have to go through the code and change the column name everywhere you used it. (In the old days, you’d use a preprocessor macro.) But here’s why I don’t like the idea in this case: If you did change the column name, you’d then find the same COL_ESTIMATED_VALUE constant in your code, but the actual column name in the database might be something completely different, like “ValGuess,” or even “FreshFactor,” leaving us with a maintenance nightmare situation for someone coming in to fix the code. It would be far better to change the constant when the column name changed, which renders the point of the constant rather moot. Using the constant then creates more maintenance work.

private const string
  STRING_VALUE_IS_NULL_EXCEPTION_MESSAGE = 
    "The string value of the application module cannot be null.";

Here’s the problem with the constant strings: The project is in English, so the constant strings are presumably used to allow for the possibility that the application might someday be translated to another language. (That’s the only non-strange reason I can think of for using constant strings like that, at least.) The idea is that when we translate the strings, we won’t have to go through all the code and find all the strings and change them. Ideally, we wouldn’t even want to have to recompile the application to change the language.

But using a const string for the message text will require not only recompiling, but handing the source code to a translater! If we truly wanted to prepare for localization, we would want to read out our strings from a resource file or XML file (I don’t know offhand what the “standard” way of localizing strings is in modern Windows programming.) Then we would only have to give the resource file to the translater.

So assuming we have a translated resource file, what would we have to do to our const strings to support it? You guessed it… rewrite it. We’d have to change every instance of STRING_VALUE_IS_NULL_EXCEPTION_MESSAGE in the code to something like LocaleManager.GetMessage( STRING_VALUE_IS_NULL_EXCEPTION_ID, STRING_VALUE_IS_NULL_DEFAULT_EXCEPTION_MESSAGE ).

The moral of this story is: If you’re going to localize your application, do it right. Otherwise, save everyone a headache and skip the constant strings.

Related