When is it better to use String.Format vs string concatenation?
For a simple case where it's a simple single concatenation, I feel that it's not worth the complexity of string.Format (and I haven't tested, but I suspect that for a simple case like this, string.Format might be slightly slower, what with the format string parsing and all). Like Jon Skeet, I prefer to not explicitly call .ToString(), since that will be done implicitly by the string.Concat(string, object) overload, and I think the code is cleaner-looking and easier to read without it.
But for more than a few concatenations (how many is subjective), I definitely prefer string.Format. At a certain point I think that both readability and performance suffer unnecessarily with concatenation.
If there are many parameters to the format string (again, "many" is subjective), I usually prefer to include commented indices on the replacement arguments, lest I lose track of which value goes to which parameter. A contrived example:
Console.WriteLine(
"Dear {0} {1},\n\n" +
"Our records indicate that your {2}, \"{3}\", is due for {4} {5} shots.\n" +
"Please call our office at 1-900-382-5633 to make an appointment.\n\n" +
"Thank you,\n" +
"Eastern Veterinary",
/*0*/client.Title,
/*1*/client.LastName,
/*2*/client.Pet.Animal,
/*3*/client.Pet.Name,
/*4*/client.Pet.Gender == Gender.Male ? "his" : "her",
/*5*/client.Pet.Schedule[0]
);
Update
It occurs to me that the example I've given is a bit confusing, because it appears that I've used both concatenation and string.Format here. And yes, logically and lexically, that's what I've done. But the concatenations will all be optimized away by the compiler1, since they're all string literals. So at run-time, there will be a single string. So I guess I should say that I prefer to avoid many concatenations at run time.
Of course, most of this topic is out of date now, unless you're still stuck using C# 5 or older. Now we have interpolated strings, which for readability, are far superior to string.Format, in almost all cases. These days, unless I'm just concatenating a value directly to the beginning or end of a string literal, I almost always use string interpolation. Today, I'd write my earlier example like this:
Console.WriteLine(
$"Dear {client.Title} {client.LastName},\n\n" +
$"Our records indicate that your {client.Pet.Animal}, \"{client.Pet.Name}\", " +
$"is due for {(client.Pet.Gender == Gender.Male ? "his" : "her")} " +
$"{client.Pet.Schedule[0]} shots.\n" +
"Please call our office at 1-900-382-5633 to make an appointment.\n\n" +
"Thank you,\n" +
"Eastern Veterinary"
);
You do lose compile-time concatenation this way. Each interpolated string gets turned into a call to string.Format by the compiler, and their results are concatenated at run time. That means this is a sacrifice of run-time performance for readability. Most of the time, it's a worthwhile sacrifice, because the run-time penalty is negligible. In performance critical code, however, you may need to profile different solutions.
1 You can see this in the C# specification:
... the following constructs are permitted in constant expressions:
...
- The predefined + ... binary operator...
You can also verify it with a little code:
const string s =
"This compiles successfully, " +
"and you can see that it will " +
"all be one string (named `s`) " +
"at run time";
Before C# 6
To be honest, I think the first version is simpler - although I'd simplify it to:
xlsSheet.Write("C" + rowIndex, null, title);
I suspect other answers may talk about the performance hit, but to be honest it'll be minimal if present at all - and this concatenation version doesn't need to parse the format string.
Format strings are great for purposes of localisation etc, but in a case like this concatenation is simpler and works just as well.
With C# 6
String interpolation makes a lot of things simpler to read in C# 6. In this case, your second code becomes:
xlsSheet.Write($"C{rowIndex}", null, title);
which is probably the best option, IMO.
My initial preference (coming from a C++ background) was for String.Format. I dropped this later on due to the following reasons:
- String concatenation is arguably "safer". It happened to me (and I've seen it happen to several other developers) to remove a parameter, or mess up the parameter order by mistake. The compiler will not check the parameters against the format string and you end up with a runtime error (that is, if you're lucky enough not to have it in an obscure method, such as logging an error). With concatenation, removing a parameter is less error prone. You could argue the chance of error is very small, but it may happen.
- String concatenation allows for null values, String.Format does not. Writing "s1 + null + s2" does not break, it just treats the null value as String.Empty. Well, this may depend on your specific scenario - there are cases where you'd like an error instead of silently ignoring a null FirstName. However even in this situation I personally prefer checking for nulls myself and throwing specific errors instead of the standard ArgumentNullException I get from String.Format.
- String concatenation performs better. Some of the posts above already mention this (without actually explaining why, which determined me to write this post :).
Idea is the .NET compiler is smart enough to convert this piece of code:
public static string Test(string s1, int i2, int i3, int i4,
string s5, string s6, float f7, float f8)
{
return s1 + " " + i2 + i3 + i4 + " ddd " + s5 + s6 + f7 + f8;
}
to this:
public static string Test(string s1, int i2, int i3, int i4,
string s5, string s6, float f7, float f8)
{
return string.Concat(new object[] { s1, " ", i2, i3, i4,
" ddd ", s5, s6, f7, f8 });
}
What happens under the hood of String.Concat is easy to guess (use Reflector). The objects in the array get converted to their string via ToString(). Then the total length is computed and only one string allocated (with the total length). Finally, each string is copied into the resulting string via wstrcpy in some unsafe piece of code.
Reasons String.Concat is way faster? Well, we can all have a look what String.Format is doing - you'll be surprised at the amount of code required to process the format string. On top of this (I've seen comments regarding the memory consumption), String.Format uses a StringBuilder internally. Here's how:
StringBuilder builder = new StringBuilder(format.Length + (args.Length * 8));
So for every passed argument, it reserves 8 characters. If the argument is a one-digit value, then too bad, we have some wasted space. If the argument is a custom object returning some long text on ToString(), then there might be even some reallocation needed (worst-case scenario, of course).
Compared to this, the concatenation only wastes the space of the object array (not too much, taking into account it's an array of references). There's no parsing for format specifiers and no intermediary StringBuilder. The boxing/unboxing overhead is present in both methods.
The only reason I'd go for String.Format is when localization is involved. Putting format strings in resources allows you to support different languages without messing with the code (think about scenarios where formatted values change order depending on the language, i.e. "after {0} hours and {1} minutes" may look quite different in Japanese :).
To sum up my first (and quite long) post:
- best way (in terms of performance vs. maintainability/readability) for me is using string concatenation, without any
ToString()calls - if you're after performance, make the
ToString()calls yourself to avoid boxing (I'm somewhat biased towards readability) - same as first option in your question - if you're showing localized strings to the user (not the case here),
String.Format()has an edge.
I think the first option is more readable and that should be your primary concern.
xlsSheet.Write("C" + rowIndex.ToString(), null, title);
string.Format uses a StringBuilder under the hood (check with reflector) so it won't have any performance benefit unless you are doing a significant amount of concatenation. It will be slower for your scenario but the reality is this micro performance optimisation decision is inappropriate most of the time and you should really be focusing on the readability of your code unless you are in a loop.
Either way, write for readability first and then use a performance profiler to identify your hotspots if you really think you have performance concerns.