C# Action delegates with Lamda expressions

The other day I was writing a program from a top-down approach. I don’t usually write code like this, unless I’m doing some test driven development. TDD is interesting because it puts the design over the implementation. By top-down I mean that I first wrote the Main method, then worked on fleshing out all the classes that I had envisioned from there. One of my main goals was for very readable code without comments.

My main method looked like this:

public static void Main()
{
  var carLot = new CarLot( "cars.xml" );
  carLot.Each( car =>
    car.StartEngine();
    car.UnlockDriverSideDoor();
  );
}

The Behavior of a Using Statement

C# comes right out of the box with it’s own garbage collector. When objects are no longer referenced and go out of scope, they are then marked for garbage collection. Some of these objects may have special properties.

They may carry handles to files, connections to databases, etc. When the garbage collector picks these objects up, it doesn’t really know what to do with these associations.

Cleverly, there is an interface to solve this. It’s called IDisposable. With IDisposable, you are required to implement one function, Dispose(). Dispose can be compared to the C++ destructor. File buffers and database connections can all be closed right within Dispose.

This seems nice, but awkward to call Dispose on an object when you are done with it. It would be nice to just nest that object in a block statement so it is easier to see from a glance when a specific object is not needed. It would also be nice if that Dispose method could be called when the block is finished.

This brings us towards a using statement. Here is an example:

ResultSet resultSet;
using( var sqlConnection = new SqlConnection() )
{
  resultSet = sqlConnection.ExecuteQuery( "select * from `products`" );
  sqlConnection.ExecuteNonQuery( "delete from `products`" );
}
...
...  //messing around with the result set
...
return resultSet;

MSTest fails to mention ignored tests

The other day I was writing some unit tests for a project I was working on. At the time, these tests contained some credentials that I both didn’t want to check-in and also didn’t want to break the build at a later date if I ever changed my password.

The test looked like this:

[Test]
public void TestLogIn()
{
  var username = "j.wein";
  var password = "123456";

  var authenticated = Directory.Authenticate( username, password );

  Assert.IsTrue( authenticated );
}