Kian Ryan (.NET, Android, Geekery)

I just read “Why Can’t Programmer’s Program” over on Coding Horror. Out of sheer curiosity, I googled “Fizz Buzz C#” just to see what some people had engineered. The idea of the “Fizz Buzz” test is to provide a starting point to prove you can write working code. Nothing complicated, but apparently 199/200 applicants can’t even do this.

I do hiring for a few of my clients, and I’m pretty much in agreement with the general community sentiments. I’ve had people across my desk quite a few times with what look to be quite distinctive backgrounds, only to fail at simple day-to-day ASP.NET coding tasks. I would recommend to anyone involved in recruiting to make their candidates sit a simple skills test to determine whether they can actually code before putting applicants in front of a client. For discussion, I submit my own Fizz Buzz answer.

using System;

public class Program
{
    public static void Main(string[] args)
    {
        for (int i = 1; i < 101; i++) // i <= 100 is also fine
        {
            Console.WriteLine(FizzBuzz(i));
        }
    }
    
    public static string FizzBuzz(int i)
    {
        if (i % 15 == 0) return "FizzBuzz";
        if (i % 3 == 0) return "Fizz";
        if (i % 5 == 0) return "Buzz";
        return i.ToString();
    }
}

That took 90 seconds to write, and we can have a conversation about why I’ve factored FizzBuzz as a method (easy unit testing), why I’m using multiple exit points (because I think in this case it adds clarity) and why I’ve not made the amazingly trivial mistake (which around 50% of the google results did) of writing i < 100.

A small bit of itch scratching.

I’ve just finished a CruiseControl.NET status monitor on Google’s gadget platform. This means you can embed it in iGoogle, JIRA, Confluence, etc. You can access it here:

http://www.orangetentacle.co.uk/iGoogle/ccnet/ccnet-gadget.xml

I’ve also submitted it to the Gadget directory, so if it’s approved (no reason why not), it’ll also appear on there.

Features

1. Colour coded statuses
2. Alerts on broken builds
3. Title Nicknames – specify different nicknames for different servers
4. Custom time intervals
5. Force Build from gadget (black box on RHS).
6. Chrome/Firefox/IE7/8 (IE6 can go hang…)

Feel free to submit ideas for improvements.

This is part rant, part discussion…

In this modern world, developing database driven applications has become pretty damn straightforward, even for us .NET coders. Start a project, grab a ORM framework of choice (Subsonic, Entity Framework, Linq 2 SQL), define a database, create your tables, generate your classes and POW! Job done.

Which is awesome. Apart from the fact that your class behaviour is now tightly defined to your database behaviour (by default, I appreciate you can change this). Which means in turn, you really should be taking great care in defining your databases, since the closer this maps your domain model, the easier your job becomes.

So why on earth leave your columns set to NULL unless you actually intend to allow NULL values? I appreciate that SQL Server allows a column as null by default, but it has so many implications if you’re not intending it it’s untrue. Lets take the following examples:

int? Age { get; set; }

if (Age > 0)
{
    Console.Writeline("This is awesome folks!");
}

int Age { get; set; }

if (Age > 0)
{
    Console.Writeline("This is awesome folks!");
}

Clearly the two are not equivalent. The first wont even compile, since the compiler has enough sense to recognise that int? could be null and therefore the expression int? > int is not valid.

It could be argued that Age may indeed be nullable, nullable indicating a genuine lack of this piece of knowledge. If this is the case, then we need to take that into account.

int? Age { get; set; }</p>

<p>if (Age == null)
    Console.Writeline(&quot;We don't have an age for this person...&quot;);
else if (Age.value &gt; 0)
    Console.Writeline(&quot;This is awesome folks!&quot;);

In this case we have a potential for three different things to be happening, all of which need to be taken into account. Each one is a semantically important case which requires understanding and testing.

But often a field being left nullable is just a sign of laziness on the part of the database being developed. The giveaway is when the following code is spotted:

int? Age { get; set; }</p>

<p>if ((Age ?? 0) &gt; 0)
{
    Console.Writeline(&quot;This is awesome folks!&quot;);
}

The ?? operator is an expressive operator used to define a default behaviour, not to correct a mistake made elsewhere by the developer. It would seem common sense to go back and change the model so that the code reflects the first example, but more often than not I see developers opting for option above.

Please use NULL wisely.