Generic dictionaries are a great thing, they let you add and retrieve objects very quickly. My current gig has a lot of need for them because we've got tons of data that needs to be quickly referenced (I'll post more about Dictionary memory performance later). The problem is that developers everywhere like to use very un-descriptive names for their dictionaries, especially nested dictionaries. Usually you'd like to avoid nesting these things, but sometimes you don't have a choice and making a bunch of derived classes adds a lot of code and more "stuff" you have to sift through.

Simple Example:

Dictionary<int, string> _peopleDictionary;

What is the key? Is it a PersonId? Is it a CustomerId? Is it an EmployeeId? Is it a Social Security Number?

What about the value? Is it First Name, Last Name, First then Last, Last then First, Nickname?

In order to find out, a developer who takes over your code has to look up all references to PeopleDictionary and find out what the Key and Values are, yielding a gigantic waste of time. (Worse yet, it could be you looking up all the references because you haven't looked at this particular code in 7 months). And that is even a non-nested dictionary!

Now, can you tell me what kind of data is stored in the below object?

Dictionary<int, Dictionary<int, List<string>>> _customerIdToOrderIdToDescriptions;

Sure the name is a little long, but think about how many different kinds of data are being stored in it. Plus you didn't have to make a custom object for a one-off need. Anyone who has to modify your code can easily use this object without trying to figure out what "OrdersDictionary" is actually storing.

FXCop Guys: I'll give you $10 if you add a rule saying that generic dictionary variable names have to contain the string literal "To".

Of note: it's generally considered bad practice to use nested generics, but if you do, just make sure that you don't expose nested generic types by returning them in public methods or by making a public property with a nested type. Keep them for internal use within your class only.

Register and attend for your local launch event and receive a free copy of Visual Studio 2008, SQL Server 2008 AND Windows Server 2008. Which by my estimate is at least $2000 in free software.

http://www.microsoft.com/heroeshappenhere/register/default.mspx

(If you're feeling generous, I would accept a 10% finders fee)

Do you ever get sick of having to write 4 whole lines for timing certain parts of your code. I know 4 lines isn't that bad, but they multiply quickly when you're testing a lot of different code, or different parts of the same method. That is why I came up with a StopwatchWriter class, it implements IDisposable so you can use it in a using statement which reduces the needed code to one line, put at the top of the code your testing (as opposed to before to setup and after to write). The constructor starts a stopwatch and when the Dispose method gets called, it stops the stopwatch and writes the time to the console, but it could easily be changed to write any type of log.

public class StopwatchWriter : IDisposable
{
    Stopwatch _stopwatch = new Stopwatch();
    string _text;

    public StopwatchWriter(string text)
    {
        _text = text + " - ";
        _stopwatch.Start();
    }

    public void Dispose()
    {
        _stopwatch.Stop();
        Console.WriteLine("stopw: "+_text + _stopwatch.ElapsedMilliseconds);
    }
}

Usage looks like:

using (new StopwatchWriter("populateStuff"))
{
    this.PopulateStep1();
    this.PopulateStep2();
}

-or-

using (new StopwatchWriter("doStuff"))
    DoStuff();

So I was getting this real sweet "Error Creating Window Handle" exception in one of my apps when I went to ".Show()" a window in the app (not during the form's construction". I found that if I commented out attaching a DataSource to the a combobox, showing the form worked fine. After reading a lot about window handles and GDI objects and getting no where, lots of trial and error commenced. Apparently Combobox does not like having the "DisplayMember" property set after the datasource is set, but only if one of the objects in the datasource has null for its DisplayMember property. (The DisplayMember was a property called "Name", if one of the objects had null for its "Name" property, it blows up). But apparently if you set the DisplayMember BEFORE you set your datasource, it is ok to have a displaymember prop be null. Oy veh.