Defensive Programming Example #1

The other day I stumbled across this bit of C# code, intended to randomly return one of four messages.

// Choose one of 4 messages to display randomly
string theMsg = "";
Random r = new Random();
    case 0: theMsg = "Hey!"; break;
    case 1: theMsg = "Whats up?"; break;
    case 2: theMsg = "Salutations."; break;
    case 3: theMsg = "Hail-"; break;
    default: throw new ArgumentException(); break;
return theMsg;

Few programmers would have trouble grokking what this code does. It’s intelligible and, in its current form, not too much of a maintenance headache. But defensive programming isn’t just about making your code intelligible; it’s about making your code tolerant to quick changes made under pressure, and incremental changes made over time, by people other than yourself, including the future version of yourself who no longer remembers the code.

In that light, this code has a lot of problems:


Coding the Tweet, Redux

A few months ago we built a simple Twitter desktop client with oAuth support using C# and .NET.

Since then, there have been some breaking changes in the Twitter oAuth implementation, including a new PIN-based authorization mechanism for desktop Twitter clients. If you’ve been getting 401 Unauthorized errors, this is probably why.


Coding the Tweet: Building a Custom Branded Twitter Application

UPDATE: The Coding the Tweet demo application and source code have been updated to support PIN-based authorization through oAuth.

With millions of users and an ecosystem saturated with over 700 custom applications, Twitter’s all the rage these days. Love it or hate it, Twitter has become a powerful medium for connecting with people and marketing your skills to a wider audience. As the saying goes:

Twitter marches on.