I have a few tables that contain a column called "Order", which is used to sort by when retrieving the data. The purpose is to keep the data in a certain order when displayed to the end user.

The problem is that SQL Server puts null values above non-null values when doing an "order by". To reverse this behavior, this was the most elegant and efficient solution that I found:

Select FooValue
From foos
Order by (Case When [Order] Is Null Then 1 Else 0 End), [Order]

I found information about the original problem here, and the solution was from Tim in the comments. Thanks!

I created a shopping cart for a website that can display multiple types of items that implement IShoppingCartItem. When the GridView would display items that were different type, I would get this exception:

Exception Details: System.Reflection.TargetException: Object does not match target type.

I found a lot of solutions that I didn’t really like. For example, every shopping cart item type could implement ITypedList.

What I ended up doing was creating a CartGridItem class that implements IShoppingCartItem:

public class CartGridItem : IShoppingCartItem
{
	private readonly IShoppingCartItem _baseCartItem;
	public CartGridItem(IShoppingCartItem baseCartItem)
	{
		_baseCartItem = baseCartItem;
	}
	#region IShoppingCartItem Members
	public string ProductCode
	{
		get { return _baseCartItem.ProductCode; }
	}
//...end of code sample...

This has worked great, and I don’t have to make any changes when I create a new item that implements that interface!

Almost every time that someone shows me a snippet of their code, I hear a comment like this:

• "This isn’t finished, I have a lot of cleanup to do"
• "I wrote this code a long time ago, it’s not very good"
• "Ignore all these bugs, I haven’t had time to fix them yet"

We’ve all done it. It’s very rare that I hear a developer that is truly proud of their code.

So why aren’t you proud of your code? Part of the reason is that we often combine planning with writing code. I know that purists don’t like that, but the reality is that there are so many details in software that perfect planning is impossible.

The other reason is that we get our code working, and keep telling ourselves that we’ll go back and clean it up later. Then you tell yourself "why fix it if it isn’t broken?" You move on to the next task, and the cycle continues.

Common things that are overlooked:

• Proper exception handling and failure modes
• Properly disposing of unmanaged resources (IDisposable)
• Inefficient coding style
• Missing documentation
• Well thought out architecture
• Comprehensive unit tests & code coverage
• Following established coding standards
• Simplifying to minimize LoC to maintain

This post was inspired by a number of personal projects that I’m releasing as open source. I found myself doing a lot of cleanup work before uploading the source. I’m regretting not spending more time on it when I had written it.

So here is my challenge for you. Write code that you’re proud of! Do a personal code review before checking in your code. Then do a peer code review. If you’re embarrassed by the code you’ve written, go back and fix it. It’s commonly known that fixing the problems early on will have massive returns in the long run.

A few months ago, I went ahead a bought an HTC Touch Smartphone. I initially wanted the Pocket PC platform, so that I could easily sync up with Outlook and have all of my contacts and appointments with me at all times. Synchronizing that information with a typical phone is very painful.

At first, I didn’t really like the HTC Touch. It’s slow (compared to a standard phone or an iPhone). The biggest issue was getting push email to work. The guy at the Sprint store claimed that you would just enter your email credentials, and push email would magically be enabled. I ensured him that it wasn’t that simple, but he still insisted.

With pocket Outlook I was able to set up access to my GMail account using IMAP. The problem was that it was slow, and push email didn’t really work at all. Research led me to the conclusion that Pocket Outlook really sucks at IMAP. I even tried another email client (Flexmail), but I still wasn’t satisfied.

Then, I found out that you could use the "Live" application on the phone to get real-time email from Hotmail using the option on the device for receiving emails "as items arrive". I signed up for a Hotmail account, and set my GMail account to forward a copy of all messages. This option proved to be very flaky, but the email delay wasn’t too bad. After doing some research, it seems as though this option pretends to be push email, but is in fact very frequent polling. I would occasionally lose my data connection, and the mail application would just give up.

Now on to the option that actually works, and the ONLY option that has worked consistently, reliably, and without much delay (5-15 seconds). Sign up for the "Live" option on Mail2web. This basically gives you your own free Microsoft Exchange account. Set up your email accounts for forward a copy of your messages to this account. Then use the credentials they supply to connect your device. On Windows Mobile 6, you can set it up in ActiveSync on your desktop, or through the device itself.

This option has worked flawlessly for me, even when I can barely get a signal. I get email no matter where I’m at, and I can save time because I don’t need to compulsively check my computer for new mail. I’m guessing this is really the only well supported option for mail, because this is how business customers would set it up.

For extra credit, I copied the XP email notification sound off my system, amplified it (using Audacity), and then set that as my mail notification. I get the recognizable email sound, which is pretty confusing to those around me when there are no computers around.

Enjoy your real-time push email!

One of the biggest traps I’ve seen developers fall into is what I like to call the "What If" game:

• "Make your ID columns integers", "But what if we want them to contain a letter eventually?
• "Let’s cook these 10 steaks", "But what if 100 people show up?"
• "Let’s go to the park", "What if we get sick?"

The "what if" game consists of over thinking your plan. Planning in general is obviously essential. However, I’ve seen an alarming rate of crippling fear. Fear to write any code because it will never possibly handle all possible scenarios. It ends up being a self fulfilling prophecy of failure.

Sometimes the side effect isn’t just a fear to write code. It often leads to code that is generic beyond usefulness. For example, a database with all columns being VARCHAR(MAX).

Specialization is basically a spectrum. At one end, we have code that is so specialized that it is basically un-reusable. At the other end, the end I’m talking about, we have code that can be used everywhere, but doesn’t really do anything.

Some of the hardest decisions we have to make as developers are related to whether we base our decisions on the present, or a potential future that has a variable amount of certainty.

I’m not saying that you should avoid planning, but your decisions need to be based on the real likelihood that changes will need to be made later. An ounce of prevention is worth a pound of cure, but 64 ounces of prevention is certainly not worth a pound of cure!