views:

326

answers:

4

For the project that I'm currently on, I have to deliver specially formatted strings to a 3rd party service for processing. And so I'm building up the strings like so:

string someString = string.Format("{0}{1}{2}: Some message. Some percentage: {3}%", token1, token2, token3, number);

Rather then hardcode the string, I was thinking of moving it into the project resources:

string someString = string.Format(Properties.Resources.SomeString, token1, token2, token3, number);

The second option is in my opinion, not as readable as the first one i.e. the person reading the code would have to pull up the string resources to work out what the final result should look like.

How do I get around this? Is the hardcoded format string a necessary evil in this case?

+6  A: 

I do think this is a necessary evil, one I've used frequently. Something smelly that I do, is:

// "{0}{1}{2}: Some message. Some percentage: {3}%"
string someString = string.Format(Properties.Resources.SomeString
                                  ,token1, token2, token3, number);

..at least until the code is stable enough that I might be embarrassed having that seen by others.

Michael Petrotta
You should also add comments to the resource file to say what the parameters are. This is very useful to localizers if the file ever goes to translation.
Coding Monkey
@CodingMonkey: agreed. Make life as easy for the localization engineers as you can. You don't want translation guesswork.
Michael Petrotta
+1  A: 

I don't see why including the format string in the program is a bad thing. Unlike traditional undocumented magic numbers, it is quite obvious what it does at first glance. Of course, if you are using the format string in multiple places it should definitely be stored in an appropriate read-only variable to avoid redundancy.

I agree that keeping it in the resources is unnecessary indirection here. A possible exception would be if your program needs to be localized, and you are localizing through resource files.

Matthew Flaschen
Yep, it's a pain, but some form of redirection is almost essential for localization. I've worked on the other side of that fence, in software localization, and trust me, you *don't* want to ship us code. Or try to merge changes back into code.
Michael Petrotta
Yes, but gettext-style localization allows keeping the original strings in code, while still shipping only a pot (template) file to translators. So resource files are not the only option.
Matthew Flaschen
+4  A: 

There are several reasons that you would want to do this, but the only great reason is if you are going to localize your application into another language.

If you are using resource strings there are a couple of things to keep in mind.

  1. Include format strings whenever possible in the set of resource strings you want localized. This will allow the translator to reorder the position of the formatted items to make them fit better in the context of the translated text.

  2. Avoid having strings in your format tokens that are in your language. It is better to use these for numbers. For instance, the message:

    "The value you specified must be between {0} and {1}"

    is great if {0} and {1} are numbers like 5 and 10. If you are formatting in strings like "five" and "ten" this is going to make localization difficult.

  3. You can get arround the readability problem you are talking about by simply naming your resources well.

    string someString = string.Format(Properties.Resources.IntegerRangeError, minValue, maxValue );

  4. Evaluate if you are generating user visible strings at the right abstraction level in your code. In general I tend to group all the user visible strings in the code closest to the user interface as possible. If some low level file I/O code needs to provide errors, it should be doing this with exceptions which you handle in you application and consistent error messages for. This will also consolidate all of your strings that require localization instead of having them peppered throughout your code.

Nick Haddad
+3  A: 

One thing you can do to help add hard coded strings or even speed up adding strings to a resource file is to use CodeRush Xpress which you can download for free here: http://www.devexpress.com/Products/Visual_Studio_Add-in/CodeRushX/

Once you write your string you can access the CodeRush menu and extract to a resource file in a single step. Very nice.

Coding Monkey