Skip to main content

The Overuse of the StringBuilder class in .NET

So this friend of mine Adam wrote this post today. The main point of the post I love, as it correctly abstracts the creation of the query string behind a class and away from the rest of the code that is consuming the query results. Why I'm writing this post is that while his post was not directly having to do with the StringBuilder class, IMHO, he is displaying what I believe is indicative of the over zealous use of the StringBuilder class.

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.

Comments

David Stull said…
I believe String.Format() uses a StringBuilder internally. I agree that the String.Format() syntax is nicer.
BigJimInDC said…
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.

Popular posts from this blog

MS KB928365, ASP.NET Request.Headers.Add() Hack No Longer Works

So a project that I am currently a part of is using an ASP.NET 2.0 HttpModule to add some additional values to the incoming HTTP request's headers in the DEV environment (i.e., our local disconnected laptops) to simulate what an enterprise single-sign-on solution is performing in the production environment. It has worked like a charm. That is until I installed the new security update for the .NET Framework 2.0 release this past Wednesday, July 10, MS KB928365.

Apparently this "hack"has been disabled with the release of this security update.

When attempting to call Headers.Add(), with or without the above hack in place, you will now receive a PlatformNotSupported exception.

All in all, this post is by no means a rant against the security update, but simply an attempt to add a quick answer to the "Google answer machine" for those searching. I am also already aware of a number of other potentially better solutions than the one currently in place for simulating th…

Temporal Database Design, Soft Deletes, and Ayende's Razor

This is a formal follow-up to a post on Ayende's blog on "Avoiding Soft Delete's" in your database where I question the lack of temporal database solutions being applied to these types of problems.

After Oren claimed the following, I felt it necessary to expand on it in a blog post of my own, rather than continuing to clutter his comments, and hopefully finally bring some traffic to my own blog :-)
Ayende’s RazorThis is a response to a comment on another post:Oren, in all seriousness, I thought that problems that were "(a) complex, (b) hard to understand (c) hard to optimize" were the kinds that folks like you and I get paid to solve...Given two solutions the match the requirements of the problem, the simpler one is the better.I could just as well call that statement "Jim's Razor", as I believe in it as much as you do Oren, so no arguments there.

But in the same vane, "wise" (i.e., experienced) software architects/developers strategical…

It was bound to eventually happen...

...that I would start a blog.

Anyway, I've spent better than the past 5 years now reading other people's blogs, and steering clear of starting my own. I still don't think I have the time to offer a lot of content, but hopefully what I do post will be more useful than this obligatory intro. The only real reason I decided to start this was to give myself somewhere to post write-ups on random topics that I couldn't find an answer to via Google. Hopefully posting those write-ups here will save someone else some time some day.

In the mean time, you can keep yourself busy reading my Google Reader Shared Posts.