A couple months back, I mentioned that I’d like to try out something new on this site, specifically, a programming contest. After a lot of thinking and a little bit of coding, I finally put one together: The Olympiad of Misguided Geeks at Worse Than Failure Programming Contest.

Unlike other programming contests, the goal of the OMGWTF contest is not to flex your algorithmic muscles and solve some abstract computational problem like you might in an ACM contest. Nor is it like the International Obfuscated C Coding Contest; in fact, writing code like that would be a surefire way to lose this contest. Instead, the goal of the OMGWTF contest is to solve an incredibly simple problem using the most obscenely convoluted way imaginable. And for this first contest, the simple problem is to build and implement the logic for a four-function calculator.

 

Defining “Bad Code”

One of the bigger challenges in figuring out the contest details was coming up with a way to make purposely “bad code” fun to write and, most importantly, fun to look at. Thinking about the different types of “bad code,” we have:

  • Ugly Code, which is unreadable, unmaintainable, and difficult to understand. We’ve all seen it plenty times (both at work and on this site): single letter variable names, no subroutines, and so on. It’s like building a bench out of rough timber.
  • Buggy Code, which simply riddled with bugs. Null pointers, memory leaks, divide by zeros, etc. It probably works most of the time when used exactly as intended, but any deviation will cause it crashing to a halt. It’s like building a bench using finishing nails and scotch tape.
  • Clever Code, which is unconventional and solves a problem that may or may not be solvable with conventional means. Duff’s Device is a good example of “clever code,” as are many of the samples seen on this site. It’s like building a bench by planting and grafting several small trees together.

Since the fine folks over at the IOCCC have already compiled some of the most beautiful Ugly Code ever created (seriously – a C-based flight simulator with code shaped like an airplane – that’s impressive), and since looking at Ugly Code is more or less what many of us do each day at work, I’ve decided to exclude Ugly Code as an option altogether. In other words, entries for this contest will need to focus on clean and human-readable code that is, first and foremost, Clever and, if desired, Buggy.

Building The Calculator

I’ve chosen C/C++ as the language for this first contest. Not only do most of you (85%, last reader survey) seem to know it, but I think C/C++ will give you more than enough rope to hang not only yourself, but the poor end user who runs your calculator. Which, I guess, would be me.

For the UI challenged, I created a Win32 skeleton solution that you may use. Having not touched C++ in nearly a decade and having only dabbled in Win16 programming once or twice (using an IDE, no less), I figured I’d be the perfect person to put it together. And after several hours of hacking and remembering the doh’s of pointers, I finally got something mostly working. Hopefully.

The idea is that anyone should be able to download the skeleton solution, fill in the “TODOs” in the code, and simply compile it. The TODOs look like this:

double DoAdd( double op1, double op2 )
{
   //TODO: return the sum of op1 and op2
}

Of course, you don’t have to use my skeleton solution, but it’s there for you if you’d prefer. For the Linux folks out there, you may use the mostly equivalent GTK skeleton solution.

Judging the Entries

I asked some of my favorite bloggers to pick out the winning entries, and being the nice guys that they are, they agreed. The OMGWTF contest judges will be Raymond Chen, Joel Spolsky, and Jeremy Zawodny.

However, before I hand off the submissions to the judges, I will go through and make sure that each one passes the requirements:

  • Meets the Tech Specs (C/C++, Win32/GTK, etc)
  • Meets the UI Specs (allows entering of numbers and displaying of answer)
  • Passes all of Test Cases

An Added Bonus: Static Analysis

If you haven’t heard of Static Analysis before, it’s definitely something you should check out. It’s a good weapon in the battle for Quality Software that sits somewhere between code review and test cases. A good Static Analysis tool can understand execution paths, user-defined types, APIs, security implications, multi-threading issues, etc. – and make sure that they’re programmed safely.

As for the Added Bonus, entries will be run through a Static Analysis tool (Coverity’s Prevent to be specific) for an objective look at how Buggy the code is or isn’t. This will present a fun opportunity to shoot for a perfect score (zero defects – how hard could that be?) or the most obscenely Buggy code (extra points for those who exceed a defect/line-of-code ratio greater than 1).

Winning The Contest

Although you’ll find plenty more details over at the OMGWTF contest site, the author of the winning entry will be awarded a High-Resolution JPEG of an Official Olympiad of Misguided Geeks at Worse Than Failure First Prize Trophy. In addition, if you’d like, I’ll toss in a brand new laptop (choice of a 15” MacBook Pro or Sony VAIO VGN-SZ430N/B) so you can view this JPEG.

There will also be some runner up prizes, but they won’t be nearly as cool the High-Resolution JPEG (or the new laptop).

Good luck to all, and make sure to check out the OMGWTF Contest Site for more details. I’ll be back tomorrow with a regular feature article.

 

UPDATE: Contest is long over, but please check out the winning entries.

 

[Advertisement] BuildMaster allows you to create a self-service release management platform that allows different teams to manage their applications. Explore how!