I agree that resource files are a good idea, especially if you’re supporting multiple languages. In that case you could extract the strings from your source code to make sure that everyone is playing by the rules. I could just imagine myself thinking “It’s just this one silly case. I don’t want to go to all the trouble of making an entry in the resource file. Besides, I know the code will never get here. I’ll just pop up a quick message box.” Then when the application is ported to French, you have one English message box. Oops!

By the way, I gave a software demo in France once. The software text was in English, and that was fine with everyone. But the software immediately ran into a problem because the decimal separator is “,” in France rather than “.” I had fired up the software on a French laptop the night before, but I only entered integers so I didn’t see the problem.

I’m reminded of one silly case of this from the early 1980s. A program I was working on had a “calculator mode” built into it, just for convenience and because it was easy. Instead of typing a command to the program (pre-GUI days, of course), you could type something like “6 * 5″, and it would type back “30″. If you typed “6 / 0″, the response was, “You can not divide by zero.”

The messages were being reviewed by the technical writers, who enforced a rule that every error message had to have an explanation in the manual, and had to tell you what you could do about it. This makes sense, in general, but, well, there are always exceptions. Not here, though, and they used the catch-all resolution: the released version of the message became, “You can not divide by zero. Contact your system administrator.”

One quibble: Stored procedures don’t solve SQL injection bugs (and they cause lots of other headaches). The important change is to use prepared statements and pass the user-supplied data in as parameters.