The code complexity extension for Visual-Studio is now compatible with 2013.

The new version is available at the Visual-Studio Gallery and the source code at CodePlex.

In this post we’ll explore what happens behind the scenes when we place code in field initializer compared to constructor body.

Field initializer and constructor

We’ll start from a simple example:

public class MyClass
{
    private static int index = 1;

    public int x = index++;
    public int y;

    public MyClass()
    {
        y = index++;
    }
}

The result here is very intuitive, this code:

var instance = new MyClass();
Console.WriteLine("x = " + instance.x);
Console.WriteLine("y = " + instance.y);

Will output:

So far there’s no surprise, the field initializers code is performed prior to code of the explicit constructor.

Field initializer and base constructor

Let’s observe the next code:

public class Base
{
    protected static int index = 1;

    public int w = index++;
    public int x;

    public Base()
    {
        x = index++;
    }
}

public class Derived : Base
{
    public int y = index++;
    public int z;

    public Derived()
    {
        z = index++;
    }
}

There are two outputs which one may expect:

• The base class fields will be initialized first and the derived ones will be initialized afterwards.
• The field y, which has a field initializer will be initialized first, then the base fields and lastly the derived constructor will be called.

What actually happens?

var instance = new Derived();
Console.WriteLine("Base.w    = " + instance.w);
Console.WriteLine("Base.x    = " + instance.x);
Console.WriteLine("Derived.y = " + instance.y);
Console.WriteLine("Derived.z = " + instance.z);

Outputs:

We can clearly see that the derived field initializer is called first, prior to the base constructor.

Why it happens?

Looking at the disassembled IL we can see that the field initializers code is placed at the beginning of the constructor code, prior to the base constructor call:

.method public hidebysig specialname rtspecialname 
        instance void  .ctor() cil managed
{
  // Code size       48 (0x30)
  .maxstack  8
  IL_0000:  ldarg.0
  IL_0001:  ldsfld     int32 ConsoleApplication1.Base::index
  IL_0006:  dup
  IL_0007:  ldc.i4.1
  IL_0008:  add
  IL_0009:  stsfld     int32 ConsoleApplication1.Base::index
  IL_000e:  stfld      int32 ConsoleApplication1.Derived::y
  IL_0013:  ldarg.0
  IL_0014:  call       instance void ConsoleApplication1.Base::.ctor()
  IL_0019:  nop
  IL_001a:  nop
  IL_001b:  ldarg.0
  IL_001c:  ldsfld     int32 ConsoleApplication1.Base::index
  IL_0021:  dup
  IL_0022:  ldc.i4.1
  IL_0023:  add
  IL_0024:  stsfld     int32 ConsoleApplication1.Base::index
  IL_0029:  stfld      int32 ConsoleApplication1.Derived::z
  IL_002e:  nop
  IL_002f:  ret
} // end of method Derived::.ctor

We can see, obviously, that the compiler is protecting us from doing silly mistakes like accessing base fields before they’re initialized:

public class Base
{
    protected int baseField = 100;
}

public class Derived : Base
{
    public int x = baseField;
}

Leads to a compilation error, while this code works perfectly:

public class Derived : Base
{
    public int x;

    public Derived()
    {
        x = baseField;
    }
}

Does it really matter?

Understanding our code

I guess that in almost all cases this will not cause noticeable difference. It will however make a difference when we’re depending on that order, or, when the field initializers call methods that depend on side effects. So for start it’s important that we understand how our code works.

Make use of it

The next thing we can do is to use the field initializers as a hack to precede base constructors code. For example, if we have this 3rd party logger:

public class MyLogger
{
    public MyLogger()
    {
        if (!Directory.Exists(@"C:\Logs"))
        {
            throw new InvalidOperationException("Can't start logs");
        }

        File.WriteAllText(@"C:\Logs\Session.log", "Initialized");
    }
}

And we want to change it’s behavior without rerouting all it’s methods (of course this is not the only way), we can initialize a dummy field with method call that creates the directory:

public class MyLoggerHack : MyLogger
{
    private bool dummy = CreateDirectory();

    private static bool CreateDirectory()
    {
        if (!Directory.Exists(@"C:\Logs"))
        {
            Directory.CreateDirectory(@"C:\Logs");
        }

        return true;
    }
}

So using this hack, we can “add” new code to the beginning of an existing call constructor without actually changing the original class.

The code complexity extension for Visual-Studio is now compatible with 2012. The new version has just been uploaded to the gallery.

The new version can be downloaded from Visual-Studio Gallery and the source code from CodePlex.

In this post I’ll introduce a less known feature of the C# language – the goto expression.

In general, we know that it is not a great idea to use goto statements in code since it raises significantly the chance of ending up with spaghetti code. Reading and understanding of spaghetti code is way more difficult and therefore its maintenance is expensive.

The case we are going to deal with is goto inside single switch statement. It results that all the labels are local – this case is usually much easier to track than distanced labels. The goto statements enable us to implement the fall through capability which is not supported out of the box in C#.

Switch fall through

In C# implicit fall through between cases in C# is not allowed. The reason for disallowing it is simple – implicit fall through is likely to cause bugs since forgetting to place a break is very common mistake. C# switch statements require each case to end with an explicit end point or a sure “never ending” code. End points are explicit expressions that transfers the execution out of the case block, these can be break, goto, throw and return. A never ending code is code that we know for sure during compilation it is never going to exit the block, such as a while loop whose condition is true.

According to these requirements it is clear that implicit fall through is not supported since we provide explicit instruction about how each case ends.

goto statements

goto in C# is simple and consistent with most languages like C and C++. It is based on labels, which are defined in the code by ‘label-name:’ followed by a C# statement. In order to jump to a label we use the goto statement with the label – ‘goto label-name;’’.

This is a simple implementation of a loop with based on goto.

public void GotoBasedLoop()
{
    int times = 3;
    int i = 0;
start:
    if (i >= times)
    {
        goto end;
    }
    
    Console.WriteLine(i);
    i++;
    goto start;

end:
    return;
}

goto statements in switch

As we’ve seen – each case must have an end point or a promise it never ends. It leads that using naïve usage of gotos we can implement the fall through – we place a label at the beginning of every case and use a goto at the end of every case we want to redirect.

Luckily, for this case C# provides a labels like behavior that simplifies the usage. Each case can be redirected to other case using a simple syntax – goto case ‘constant’ or goto default. Using this syntax we can avoid a duplicate label for fall through.

This usage can be exampled by a simple code that “counts” asterisks:

static int GetLength(string s)
{
    int x = 0;

    switch (s)
    {
        case "*":
            x++;
            break;
        case "**":
            x++;
            goto case "*";
        case "***":
            x++;
            goto case "**";
    }

    return x;
}

As can be seen, each case is redirected to a different case using the built in mechanism.

Summary

Fall through is probably not the most common feature that developers look for. Since implicit fall through is more likely to cause bugs than simplify coding the C# designers decided to leave it out of the language. For those cases where we want to keep things simple – avoid extracting code to a method just for reuse or instead to create code duplication – we can use the simple solution of redirecting cases using goto.