Some functions expect an array with a minimum size. While this is generally bad coding sometimes you can’t avoid it (e.g. with csv files).

That’s when this piece of code comes in handy: (it’s an extension method, so it only works on .NET 3.5)

public static class ArrayHelper
{
    /// <summary>
    /// Expands an array to the given <paramref name="size"/>
    /// </summary>
    /// <typeparam name="T">The type of the array (not neccesairy, can be infered).</typeparam>
    /// <param name="array">The array</param>
    /// <param name="size">The size it should become</param>
    /// <returns>The array expanded to the given size</returns>
    public static T[] Expand<T>(this T[] array, int size)
    {
        if (size < array.Length)
        {
            throw new ArgumentException("size < array.Length, this will cause data to be truncated, canceling", "size");
        }

        T[] list = new T[size];

        for (int index = 0; index < array.Length; index++)
        {
            list[index] = array[index];
        }

        return list;
    }
}

Usage:

class Program
{
    static void Main(string[] args)
    {
        string[] array = new string[] { "test1", "test2", "test3" };

        //array1 has a length of 3
        Console.WriteLine("array.Length = {0}", array.Length); 

        array = array.Expand<string>(10);

        //now array has a length of 10
        Console.WriteLine("array.Length = {0}", array.Length);

        Console.ReadLine();
    }
}

Enjoy

This is something I’ve been thinking about a lot. When do I throw an exception? Do I program with exceptions? Do I catch those exceptions.

Consider this piece of code:

public Product GetProduct(int id)
{
    //get the product, or null if not found
    Product p = //...

    return p;
}

Now you can ask yourself the following question:

Is it ok to return null if the product is not found? After all, the calling layer assumes that we’ll be getting a Product, not a null.

So now the calling layer needs to check if the product != null.

It would be exceptional if no product was found.

So in my opinion you throw an exception if no product is found. And that get’s handled in the calling layer.

But on the other hand: if you would just return a null and test on that in the calling layer you would use less resources since exception throwing is expensive.

I’d still go with the first one since it goes better with my consume code thoughts.

But this is an agreement you need to make across your team, and across your API.

So yesterday I reinstalled my laptop because some beta driver was acting up, no big deal. I had both of my partitions secured with Bitlocker (and a BIOS password set up) so that my laptop is secure.

After formatting I noticed that my C drive wasn’t encrypted anymore (which is obvious, it was formatted).

But my D drive looked like this:

It was locked. Fortunately I printed my recovery key so I was able to unlock the drive.

Please print the keys, and keep them safe!

Well not really my computer, but my girlfriend’s. It needed some updating (you know how people are, not updating & stuff).

Adobe Reader already sets 2 programs in startup. A speed launcher and another one which I am too lazy to identify. If your application is too slow then optimize it, don’t treat the symptoms.

Then our good slow friend Java. Always had their speed launcher (symptom treatment!!) in startup, but guess what also added a service.

What the f*ck? I’m moving closer and closer to not install Java on new pcs, since it’s a burdon to manage and keep up to date!