What I’ve Learned: Untangling Strings

What I’ve Learned: Untangling Strings

How many times do you find yourself writing code like this to display multiple lines of text using the MessageBox object, or in a TextBox?

Imports System.IODim i As IntegerDim strOut As StringDim di As DirectoryInfo = _ New DirectoryInfo("C:")For Each fi As FileInfo In di.GetFiles("*.*")  strOut = strOut & "File " & _   i.ToString & ": " & _   fi.Name & Environment.NewLine  i += 1NextMessageBox.Show(strOut)

This example poses lots of problems. First, it uses very slow string concatenation, but I’m not going to focus on efficiency here. The real problem for me is that it’s hard to read, and hard to maintain (and it’s slow, because of string concatenation). Many developers might suggest that you use a StringBuilder instance, calling the Append method for each file you find, like this:

Imports System.IOImports System.TextDim i As IntegerDim sb As New StringBuilderDim fi As FileInfoDim di As DirectoryInfo = _ New DirectoryInfo("C:")For Each fi In di.GetFiles("*.*")  sb.Append("File " & _   i.ToString & ": " & _   fi.Name & Environment.NewLine)  i += 1NextMessageBox.Show(sb.ToString())

To be honest, I’ve seen friends of mine who speak a lot in public say, point blank, that developers should always use the StringBuilder class instead of the String class, whenever working with strings. That blanket statement is awfully misleading. The StringBuilder class isn’t a “magic bullet.” It doesn’t somehow just make string handling faster. There’s some overhead in allocating the memory it uses, and there’s some overhead in reallocating space when its internal buffer gets filled.

I’d like to revise the “use StringBuilder instead of String” dogma to at least add “if you’re going to make multiple modifications to the same string.” Perhaps five modifications should be your dividing line. In any case, the problem is that the String class can’t modify its contents in place (its contents are “immutable,” to quote the documentation), so it must always return a new string each time you make any changes to its contents. Creating and returning a new string can be slow, so if you do it often, the StringBuilder class (which maintains a large internal buffer, and only extends the buffer as necessary) can be more efficient.

But back to work. The previous technique works, and it works more efficiently. To be honest, however, I also don’t like concatenating all those bits and pieces to create the output string. You might improve the code a little by calling String.Format in the call to StringBuilder.Append, like this:

sb.Append(String.Format( _ "File {0}: {1}{2}", _ i, fi.Name, Environment.NewLine))

This works, and it’s a bit more readable. If you find yourself doing this sort of thing (that is, writing multiple lines to some output), however, try out the StringWriter class. This class simply writes to an internal buffer as if it was a stream, and will call the String.Format method for you! That is, you can rewrite the previous example like this:

Dim i As IntegerDim sw As New StringWriterDim fi As FileInfoDim di As DirectoryInfo = _ New DirectoryInfo("C:")For Each fi In di.GetFiles("*.*")  sw.WriteLine("File {0}: {1}", _   i, fi.Name)  i += 1NextMessageBox.Show(sw.ToString)

The StringWriter.WriteLine method takes care of adding the carriage return/line feed for you, and also allows you to supply a template with replaceable parameters, just as if you’d called the String.Format method. I’ve used this class often, and really like it. It’s easy to lose it within all the different techniques for handling string buffers within the .NET Framework, but remember, next time you find yourself concatenating strings with carriage returns between them.

When working with strings, avoid being pokey?look into the StringBuilder and StringWriter classes instead.


About Our Editorial Process

At DevX, we’re dedicated to tech entrepreneurship. Our team closely follows industry shifts, new products, AI breakthroughs, technology trends, and funding announcements. Articles undergo thorough editing to ensure accuracy and clarity, reflecting DevX’s style and supporting entrepreneurs in the tech sphere.

See our full editorial policy.

About Our Journalist