Coolest Code I’ve Written in a While

I’ve been working double time trying to finish an implementation for my job. Today I was able to bring together all of my hard work into an easy to use API and I’ve now realized what the hell I have been building.

As with most code and projects that I start, they begin as just an idea and then they slowing mature into “the big picture”. My project has finally reached “the big picture” status. I didn’t really realize it until late yesterday and mostly today (as I’ve been using my API). When I realized it, I literally threw myself back in my chair and threw my hands up and said “WHOA!?”. For example, look at the following method:

/// <summary>
/// Converts all cell references and spans to pixels.
/// </summary>
/// <param name="pixelsPerCell">A CellSpan that determines how many pixels will up the new cell.</param>
/// <returns>A CellContext transformed to pixels.</returns>
public CellContext ConvertToPixels(CellSpan pixelsPerCell)
{
    return ((CellRange) this)*pixelsPerCell;
}

To the naked eye, it may seem simple. However, for me, I know what it took to get here; that single return statement executes about 30 lines of code underneath using operator overloading and implicit casting calls on multiple classes.

To understand what the method above does, here is a quick example. Assume that you have a table of 2 rows and 2 columns. Therefore:

0,0	0,1
1, 0	1,1

Now we want to create a table layout with a single cell spanning the left side. So:

var left = new CellContext(0, 0, 2, 1);

var topRight = new CellContext(0, 1);

var bottomRight = new CellContext(1, 1);

var table = new Table(left, topRight, bottomRight);

Will create a layout like this:

Here are the facts about the left cell:

• cell start @ cell [0, 0]
• cell spans 2 rows & 1 column
• cell ends @ cell [1, 0]

Now let’s convert this layout a 20 by 20 table. There are many reasons we might need to do this. The best reason (and the reason that I wrote these classes) was to be able to convert a series of cell indexes and row/column spans to actual screen coordinates.

var pixelOffset = new CellSpan(20, 20);

table.ConvertToPixels(pixelOffset)

Here are the new facts about each cell now:

Cell [0, 0]

• cell starts @ cell [0, 0]
• cell spans 40 rows & 20 columns
• cell ends @ cell [39, 19]

Cell [0, 1]

• cell starts @ [0, 20]
• cell spans 20 rows & 20 columns
• cell ends at cell [19, 39]

Cell [1, 1]

• cell starts @ cell [20, 20]
• cell spans 20 rows & 20 columns
• cell ends at cell [39, 39]

Now, keep in mind that I’ve only dealt with 4 cells and a have only shared a very brainless example. However, I’ve been building this to deal with large amounts of cells and complex configurations. The beauty is that no matter how much math I throw at it, it continues to work. :) For example, consider the following:

var context = new CellContext(37, 19, 14, 13);

var pixelOffset = new CellSpan(23, 17);

var pixels = context.ConvertToPixels(pixelOffset);

It goes without saying that I also created a method to convert back to relative indexes from pixels using division rather than multiplication. My unit tests are all passing for it as well. :)

Perhaps I’m just a geek and this excites way too much??