.Finalize() - What I've Learned: Airline Lavatories and Strings

Here's what I've learned: If you sit in the front row on an airplane, you'd better not do something you don't want everyone on the plane to see. Last summer, I took a trip from Los Angeles to Washington DC. A long ride. I had purposefully requested the bulkhead row at the front of the coach section (didn't get upgraded on this one) so I could get some work done. Because of the never-ending weight-loss cult by which I've been brainwashed, I drink a lot of water. I have clean insides. This also means that the water must have somewhere to go, often at inopportune times. Luckily, because of my seat location, I didn't have far to wander to take care of things.

United Airlines must have a policy by which the flight attendants are instructed to lock the lavatories during takeoff, so folks like me don't jump out of their seats before the plane has reached a safe cruising altitude (really, is there such a thing?) and head for the facilities. Ten minutes into this particular flight, nature took its course, and I was in great pain. Figuring that I was willing to take my chances, I waited until the last possible moment and surreptitiously climbed out of my seat. As quietly as I could, I attempted to open the bathroom door. Curses! Foiled again. It was still locked. I'm thinking that I didn't have long before I'd be really embarrassed, so I attempted to figure out a way to get in.

I had noticed two little spring-loaded catches, one at the top and the other at the bottom of the door. The 12-year-old in me figures that if I undo those catches, the door will open. So I did, and it did. Unfortunately, it opened by falling off its hinges. Completely fell off. No way to hide. Watched by the multitudes in steerage, I was left holding the door, in despair. What does one do in this situation? I propped up the door and sheepishly sat down, hoping no one was looking.

Of course, biology doesn't give up just because there's no available privacy, and others needed the facilities by this time as well. The friendly flight attendant approached. Feeling a little like Bart Simpson, I went for the "I didn't do it!" look on my face. After another ten minutes of fiddling, we were able to finally attach the door back on its hinges and proceed as planned. (In case you were wondering, simply sliding the Occupied sign within its track locks and unlocks the door. What fun you can have, next time you fly, trying this out while the door is locked and you're awaiting your turn!)

Speaking of things I've learned, 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.IO

Dim i As Integer
Dim strOut As String

Dim di As DirectoryInfo = _
 New DirectoryInfo("C:\")
For Each fi As FileInfo In di.GetFiles("*.*")
  strOut = strOut & "File " & _ i.ToString & ": " & _
   fi.Name & Environment.NewLine
  i += 1
Next
MessageBox.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.IO
Imports System.Text

Dim i As Integer
Dim sb As New StringBuilder
Dim fi As FileInfo

Dim di As DirectoryInfo = _
 New DirectoryInfo("C:\")
For Each fi In di.GetFiles("*.*")
  sb.Append("File " & _ i.ToString & ": " & _
   fi.Name & Environment.NewLine)
  i += 1
Next
MessageBox.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 Integer
Dim sw As New StringWriter
Dim fi As FileInfo

Dim di As DirectoryInfo = _
 New DirectoryInfo("C:\")
For Each fi In di.GetFiles("*.*")
  sw.WriteLine("File {0}: {1}", _
   i, fi.Name)
  i += 1
Next
MessageBox.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.

If nothing else, you walk away from this month's missive knowing the secrets of airline lavatories. Remember, kids, it's the Occupied sign that controls the locking, not those tempting spring-loaded catches at the top and bottom! When working with strings, avoid being pokey?look into the StringBuilder and StringWriter classes instead. Either way, you'll be glad you learned something new today.