Posted on

Viking Law #1

Today, while reading this old post from Emil Gustafsson about the Viking Laws and how they can be projected into the software development context, I just can’t stop thinking that his first law interpretation is missing one of the most important, if not not the most important, commandment.

Law #1 is all about bravery and aggressivety, and according to Emil it can be projected into software development as:

  • Be direct
  • Grab all opportunities
  • Use varying methods of attack
  • Be versatile and agile
  • Attack one target at a time
  • Don’t plan everything in detail
  • Use top quality weapons

I totally agree with all these commandments but one is missing and I think it should be the first:

  • Choose your targets wisely

Never attack a target when you know you’re not enough skilled to win. Sometimes the greatest bravery you can show is to recognize you’re not ready.

Posted on

Enum types, FlagsAttribute & Zero value – Part 2

In my previous post I wrote about why you should pay attention when using enum value Zero.

After reading that post you are probably thinking like Benjamin Roux: Why don’t you start the enum values at 0x1?

Well I could, but doing that I lose the ability to have Sync and Async mutually exclusive by design. Take a look at the following enum types:

[Flags]
public enum OperationMode1
{
    Async = 0x1,
    Sync = 0x2,
    Parent = 0x4
}

[Flags]
public enum OperationMode2
{
    Async = 0x0,
    Sync = 0x1,
    Parent = 0x2
}

To achieve mutually exclusion between Sync and Async values using OperationMode1 you would have to operate both values:

protected void CheckMainOperarionMode(OperationMode1 mode)
{
    switch (mode)
    {
        case (OperationMode1.Async | OperationMode1.Sync | OperationMode1.Parent):
        case (OperationMode1.Async | OperationMode1.Sync):
            throw new InvalidOperationException("Cannot be Sync and Async simultaneous");
            break;
        case (OperationMode1.Async | OperationMode1.Parent):
        case (OperationMode1.Async):
            break;
        case (OperationMode1.Sync | OperationMode1.Parent):
        case (OperationMode1.Sync):
            break;
        default:
            throw new InvalidOperationException("No default mode specified");
    }
}

but this is a by design constraint in OperationMode2. Why? Simply because 0x0 is the neutral element for the bitwise OR operation.

Knowing this singularity, replacing and simplifying the previous method, you get:

protected void CheckMainOperarionMode(OperationMode2 mode)
{
    switch (mode)
    {
        case (OperationMode2.Sync | OperationMode2.Parent):
        case (OperationMode2.Sync):
            break;
        case (OperationMode2.Parent):
        default:
            break;
    }

This means that:

  • if both Sync and Async values are specified Sync value always win (Zero is the neutral element for bitwise OR operation)
  • if no Sync value specified, the Async method is used.

Here is the final method implementation:

protected void CheckMainOperarionMode(OperationMode2 mode)
{
    if (mode & OperationMode2.Sync == OperationMode2.Sync)
    {
    } else { 
    }
}

All wrote above prove that Async value (0x0) is useless from the arithmetic perspective, but, without it we lose readability.

The following IF statements are logically equals but the first is definitely more readable:

if (OperationMode2.Async | OperationMode2.Parent)
{
}

if (OperationMode2.Parent)
{ 
}

Here’s another example where you can see the benefits of 0x0 value, the default value can be used explicitly.

    <my:Control runat="server" Mode="Async,Parent">

    <my:Control runat="server" Mode="Parent">