Patrick Steele's .NET Blog

IsNothing? Definitely!

While reviewing some existing code at my new job I noticed that they use the VB.NET IsNothing() function instead of using the "Is Nothing" syntax. I didn't even know there was an "IsNothing" function so I compiled some code and checked it out with ILDASM. Here's what I compiled:

Public Sub Foo2()
    Dim o As AppDomain

    If IsNothing(O) Then
        Debugger.Break()
    End If
End Sub

At the resulting IL is:

.method public instance void  Foo2() cil managed
{
  // Code size       18 (0x12)
  .maxstack  1
  .locals init ([0] class [mscorlib]System.AppDomain o)
  IL_0000:  nop
  IL_0001:  ldloc.0
  IL_0002:  call       bool [Microsoft.VisualBasic]Microsoft.VisualBasic.Information::IsNothing(object)
  IL_0007:  brfalse.s  IL_000f
  IL_0009:  call       void [mscorlib]System.Diagnostics.Debugger::Break()
  IL_000e:  nop
  IL_000f:  nop
  IL_0010:  nop
  IL_0011:  ret
} // end of method Module1::Foo2

Ahhh... There's a call to the VisualBasic library. Let's see what Information.IsNothing does:

.method public static bool  IsNothing(object Expression) cil managed
{
  // Code size       5 (0x5)
  .maxstack  2
  .locals init (bool V_0)
  IL_0000:  ldarg.0
  IL_0001:  ldnull
  IL_0002:  ceq
  IL_0004:  ret
} // end of method Information::IsNothing

If your IL is a little rusty, allow me to translate it for you into VB.NET:

Public Shared Function IsNothing(ByVal Expression As Object) As Boolean
    Return (Expression Is Nothing)
End Function

Yup! A call to IsNothing() isn't inlined into a simple check for null. It's a function call. That will check for null. I was baffled when I found this. Why spend time developing such a method? Since this is Microsoft I assume there were functional designs, technical designs, code reviews, peer reviews, unit tests, etc... Just for a one-line function that could have very easily been inlined by the VB.NET compiler. I always assume when something seems so obviously wrong there must be something I'm missing...

Setting value types to Nothing?

Why in the world does VB.NET let you assign 'Nothing' to a value type? It's not that big of a deal unless you've got a structure. Consider this simple structure:

Structure ABC
    Dim first As Integer
    Dim second As String
End Structure

For some really odd reason (I haven't googled for this yet), the following code is legal in VB.NET and compiles:

Dim o As ABC = Nothing

Does the code act any differently that if I hadn't set it to nothing? Not really. Unless you look at the IL. Setting that variable 'o' (a structure) to Nothing produces the following IL:

  .locals init ([0] valuetype NothingValue.Module1/ABC o)
  IL_0000:  nop
  IL_0001:  ldnull
  IL_0002:  dup
  IL_0003:  brtrue.s   IL_0015
  IL_0005:  pop
  IL_0006:  ldtoken    NothingValue.Module1/ABC
  IL_000b:  call       class [mscorlib]System.Type [mscorlib]System.Type::GetTypeFromHandle(valuetype [mscorlib]System.RuntimeTypeHandle)
  IL_0010:  call       object [mscorlib]System.Activator::CreateInstance(class [mscorlib]System.Type)
  IL_0015:  unbox      NothingValue.Module1/ABC
  IL_001a:  ldobj      NothingValue.Module1/ABC
  IL_001f:  stloc.0

Yikes!! I'm no IL expert by any means, but what the heck is all of that? I've browsed through the OpCodes class to try and figure out some hidden meaning behind this and it hasn't hit me yet. I mean, look at those first few instructions -- pushing a null onto the evaluation stack, duplicating it and then checking if that is true? I'm sure this would get optmized out by the JIT, but having to go through a Activator.CreateInstance along with an unboxing seems a little excessive.

Finally, I don't want to make this into a language war, but C# won't even let you compile code that tries to set a value type to null.

ABC o = null;

Error!

Cannot convert null to 'Class1.ABC' because it is a value type

What about NumLock?

Time to move on.

It's time to move on to new opportunities. My current employer has accepted my two week notice. I've got a little bit of coding and documentation to finish up. This will probably be the last bit of VB6 coding I do for the foreseeable future. It's been a fun 4 1/2 years and I've worked with a great bunch of people -- including one of the best architects I've had the pleasure to work with.

But on Monday, May 23rd I start my new job at Hollywood Software! They've got some really nice .NET apps under development. I'm not sure how much I can say yet so I'll leave it at that. :) I'm looking forward to developing with .NET in a full-time capacity. I'll actually be working with some old co-workers from a couple of previous jobs. That will make the transition much easier. Plus, until the Michigan office is opened, I'll be working out of my house. Goodbye commute!

The value of unit testing.

Last week, Raymond Lewallen posted a refactoring pattern quiz. A lot people view refactoring as a "bad thing" since you're taking existing, debugged (sometimes in-production) code and changing it. While there is definitely the riesk of introducing regression bugs, Raymond addressed an important point in deflecting some of that risk:

...you will ALWAYS want to write a unit test for your initial code and make sure it passes all scenarios BEFORE beginning your refactoring process and DURING and AFTER your refactoring process.