Okay, that title is a bit of a brain twister. Hear me out though, I promise I'll eventually make some kind of sense.

Since the late 60′s, a type of computer-related essays, namely so-called "considered harmful" essays, became popular.

Considered harmful essays are all about writing page up and page down about why something programming related is bad and should be avoided. The first considered harmful essay, at least the first somewhat mainstream one, was written in 1968 by the Dutchman Edsger W. Dijkstra It was called "Go To Statements Considered Harmful", and, as you might have guessed by now, is about how GoTo statements have a tendency to produce some really messy spaghetti.

After Dijkstra's essay, the style of writing got so popular you could say it became a clich. We got a metric ton of "considered harmful" essays, each essay nitpicking on its own small area. With statements, XSL, Java, the "new" keyword, namespaces - all of which, and more, considered harmful by someone or another.

One of the later additions to the considered harmful family of essays is "'considered harmful' essays considered harmful".

Now, what's harmful about "'considered harmful' considered harmful" essays?

Well, one of the more obvious effects it has, is this post. I mean, "'Considered Harmful' essays considered harmful" essays considered harmful. If that title doesn't blow your brain out of your ears, I don't know what will.

But it doesn't stop with molten brains. Oh no, far from it. You see, considered harmful essays aren't really necessarily there to tell you not to do or use whatever the essay is about. It works more like a warning. Not as much "don't do x", but "before you do x, make sure you know what you're doing".

There are lots of new programmers out there. I myself am fairly new. With the extreme levels of abstraction in the languages which are considered great for beginners, it's easy to do something which in the code looks completely sane, but when a virtual machine runs it, it forces the CPU to do a gazillion operations. If you had taken a slightly different approach to the problem however, it would only have taken a few billion operations.

Or things could behave unexpected. For instance, the language could suddenly decide that nope, that variable (everything's variables these days - goodbye data types) is passed by reference, while all other variables are passed by value. This can have gastronomical implications, and completely break a project.

Many considered harmful essays are there to tell you about those pitfalls of leaky abstractions.

In addition to the informative value, they're a joy to read. I myself do at least love reading a well written considered harmful essay.

Someone called Xeomorpher made a thread on the Open Redstone Engineers forum (more about ORE some here), asking what people's worst pieces of code were. I wrote a response, which I might as well post here too:

TequilaJumper!

Made for Ludum Dare with minimal amounts of experience, it's not of my prettiest of works. It did however spawn some offspring in the form of xeo's TofuJumper.

Because of open sourceness, the source code can be found here: https://github.com/mortie/tequilaJumper

So, let's have a look at it shall we?

You don't even have to look at any of the source code to find the first horrible decision. Everything in one file. One index.html, containing almost 800 lines of source code. Yeeah.

Opening the file, we see some disastrous code. Take for instance this draw code: [line 218]

gameCtx.fillStyle = "rgba(0, 0, 0, 0.5";
gameCtx.beginPath();
gameCtx.moveTo(Math.floor(platformStartX[i] + platformWidth[i]/2), Math.floor(drawYModifier(platformStartY[i] + platformHeight[i]/2, 0))); 
gameCtx.lineTo(Math.floor(platformEndX[i] + platformWidth[i]/2), Math.floor(drawYModifier(platformEndY[i] + platformHeight[i]/2, 0)));
gameCtx.stroke();

Beautiful, right? That was the code for drawing lines marking the path of moving platforms (play the game for yourself, and you'll see what I mean).

This one-liner is quite extraordinary too: [line 271]

gameCtx.fillRect (Math.floor(platformX[i]), Math.floor(drawYModifier(platformY[i], platformHeight[i])), Math.floor(platformWidth[i]), Math.floor(platformHeight[i]));

Yeeah, that's one line. Believe it or not.

In the code for handling the movement of platforms (which is a complex mess of work too by the way, starting at line 283 and ending at 349): [line 324]

//HAAAAAACK!
platformMovementInvertedX[i] = platformMovementInvertedY[i];

Encountered a bug I didn't manage to fix, so I simply hacked my way around it using an extremely dirty trick.

Another thing, which isn't as clearly expressed in the code, but maybe is worst of them all:

When a platform is disappearing off of the screen, it doesn't really disappear. It's still stored in memory - it doesn't get overwritten by new platforms. This leads to a horrible memory leak. That's right. Platforms never despawn.

That's a selection of the worst parts of the code. Other ineresting areas are:

• character controls [line 411]
• collision detection [line 451]
• hack to get the player to stick to the platform [line 511]
• init [line 685]

Oh, and I almost forgot:

Almost all variables are global. Just look at the variable declaration part [line 7-73] :S

In my defence, it was made for Ludum Dare, AND I attended a party which took most of my weekend. The time was therefore short. It also kinda feels wonderful to hack away on code, not spending a single thought on structure, and just see where you end up. The code becomes extremely horrible and unreadable, but it's rather fun :P