A sweeeeet commenting tip

No no no...this isn't another typical post splurging about how you should comment your code, just another sweet tip I got from a good friend of mine. If you've been coding for a while you'll run into a time where you have 2 sections of code that you need to edit. However, you can only have 1 section commented, and the 2nd section uncommented, or vice versa. Even with the built-in keyboard shortcuts (Ctrl+K, Ctrl+C) and (Ctrl+K, Ctrl+U), it's still a pain in the behind. To the rescue!

/*   OR  //*
1ST SECTION OF CODE
/*/
2ND SECTION OF CODE
//*/

All you need to do is swap between /* and //* on the first line of code, and you can easily and quickly swap comments between the 2 sections of code. Very handy at times...

An Unfortunately Too Well Hidden Tool

Alright, maybe it's not THAT well hidden, but it's well hidden enough that most developers don't even know it exists, yet I find it to be probably one of the top 3 tools of Visual Studio that I find most useful. What is it? Break into debugger at any uncaught exception. Yep! There's actually a feature that can do that! You don't have to pull your hair out trying to figure out what exception is causing your program to mess up or when it gets swallowed. You can find the option under Debug -> Exceptions. This also brings into the discussion about what the purpose of exceptions are. I'm from the school of thought that exceptions are...well...exceptions. Exceptions should occur rarely, not regularly, otherwise they shouldn't be called exceptions. I dread finding code that uses exceptions to break out of methods/functions. If you program like that you'll probably be quickly annoyed by turning on the feature above because it'll break into the debugger a lot. While there's always a time where it can be justified, the mass majority of the time it's a bad idea to use exceptions to control program flow.

The Infamous IDisposable Pattern

At one point or another, any .NET developer should come across the concept of implementing the IDisposable pattern. For more detail, visit this excellent article at http://www.codeproject.com/KB/cs/idisposable.aspx. One of the most common errors of programmers with a C++ background is that they define the Finalize() method with ~() syntax. This is almost always wrong. Just like you should never call GC.Collect(), you should not define a finalizer most of the time. The destructor is only required if your class uses unmanaged resources. If it does, then you should implement both the destructor and IDisposable, which simply contains a public Dispose() method which is where you deterministically clean up resources. Finalizers are called during garbage collection. The typically class template is this:

class Foo : IDisposable {
  private bool _disposed = false;
  ~Foo() {
    Dispose(false); // this is called automatically by the GC when you forget to call Dispose() explicitly.
  }
  public void Dispose() {
    Dispose(true);
    GC.SuppressFinalize(this); // this prevents the GC from calling the finalizer, since you deterministically cleaned up resources already by calling Dispose().
  }
  protected void Dispose(bool disposing) {
    if (disposing) {
      //dispose unmanaged resource
    }
    _disposed = true;
  }
}

Since I'm on the subject of IDisposable, please for the love of God, use the keyword 'using' whenever possible. It makes the code much cleaner, easier to read, and safer. Compare the following:

public void Print(string path) // implemented with using
{
  try
  {
    using (StreamReader r = new StreamReader(path))
    {
      string line;
      while ((line = r.ReadLine()) != null)
        Console.WriteLine(line);
    }
  }
  catch { }
}

public void Print(string path) // implemented without
{
  StreamReader r = null;
  try
  {
    r = new StreamReader(path);
    string line;
    while ((line = r.ReadLine()) != null)
      Console.WriteLine(line);
  }
  catch { }
  finally
  {
    if (r != null)
      r.Close();
  }
}

I don't think I need to tell you the 1st section of code is much cleaner, robust, and easier to read than the 2nd section of code. The finally section is crucial as well. If you don't have this section, and some part of your code throws an exception, you probably just leaked resources. Just because .NET has a garbage collector does NOT mean you can be lazy about memory. You can and you will leak memory if you're not mindful of these things.

The Importance of Color Schemes

It is surprising to me how few people use custom color schemes and just stick with the IDE defaults. I'm not saying that the ones shipped with Visual Studio are bad, quite the contrary. They are good, but it can be better. Since VS2005, we've been given the option of having different colors for classes, value types, delegates, enumerations, and interfaces. I consider this to be one of the single most useful features in the IDE. Let's take a look at the following comparison: The first thing you'll probably notice is that I program on a black background. I find this to be easier on the eyes. It takes some getting used to at first, but once you go black you don't go back :-) These are the colors I use (or slight variations) and it helps me tremendously in keeping track of what's what. It also prevents the need to use any ugly prefixes for any variable names. Another reason I use a black background is that it's much easier to tell the difference between different shades of colors on a black background than it is on a white background. Anyways, it should be clear that my custom color scheme provides much more information than the default color scheme. At an immediate glance of the code you know exactly what is a delegate and what is a class. There is no dependence on the name or anything else. And since we can read colors faster than we can read words, this will increase your productivity. The most important one, in my opinion, is the one that differentiates reference types from value types. C# lets you declare instances on the heap or on the stack, although they have the same syntax. The compiler is smart enough to tell the difference though, so you should take advantage of that and have the colors different.

GC.Collect Is Bad For You

Sometimes I wish Microsoft didn't include this method in the API because it promotes bad programming. I've seen people use this in their code and 99.99% of the time, it is incorrect to do so. I came across a program which had many try/catch/finally blocks which had GC.Collect() in the finally block. C# has a garbage collector so you, the programmer, does not have to worry about cleaning up memory. In fact, it's optimized in such a way that it only collects memory when it needs to. By manually calling GC.Collect(), you are preventing the JIT from doing its job properly. Not only that, GC.Collect() is expensive operation. It searches every reference in memory to see if there are other objects pointing to them, and if there are no references, it cleans up and removes it from memory. Something this heavy should definitely not be called without a good reason. Summary, do not call GC.Collect(). If you want to manage memory, use another language.