For the sake of convenience, this is how he wrote it:
private static string BuildDefaultViewQuery()
{
var builder = new StringBuilder();
builder.Append("<Where>");
builder.Append("<Eq><FieldRef Name='DefaultView' /><Value Type='Boolean'>");
builder.Append("1");
builder.Append("</Value></Eq></Where>");
return builder.ToString();
}
This is how I would have written the guts of this method:
private static string BuildDefaultViewQuery()
{
return String.Format(@"
<Where>
<Eq>
<FieldRef Name='DefaultView' />
<Value Type='Boolean'>{1}</Value>
</Eq>
</Where>",
1);
}
I just happen to think that there is too much "noise" when using a StringBuilder for this kind of stuff. Yes, if you're looping through a potentially large set of data and producing a potentially large string as a result, then by all means, use a StringBuilder, as that is what you should be doing. But if you're just building a relatively static string, with a handful of "variables" inserted into the string, use String.Format() in conjunction with a string that supports line breaks (i.e., using the @"" syntax). The resulting code is so much easier to read and understand what is really going on besides the building of a string.

2 comments:
I believe String.Format() uses a StringBuilder internally. I agree that the String.Format() syntax is nicer.
I believe this web page covers this well enough from a performance point of view:
http://stackoverflow.com/questions/6785/is-stringformat-as-efficient-as-stringbuilder
As my point, per the specific example, had nothing to do with performance-bound scenarios and everything to do with style in non-performance-bound scenarios, I'm not going to change my stance on this. Unless you're sitting in a loop concatenating strings, or concatenating relatively large strings (i.e., greater than a couple thousand characters), String.Format() is the way.
Post a Comment