A friend of mine sent me this list of anti-patterns common in software engineering. Being the lone developer on my team, I don’t get to see anyone else’s code except mine on a project. As a result, it’s hard to critique whether my code is “good” or not. That was one of the benefits of working at a company I suppose. Being surrounded by those with more experience than me, I would learn a lot just from an afternoon of working on a section of code that wasn’t mine. Now I tend to have to seek out code that isn’t mine to get a sense of how things are done “well” or what not to do.

It was interesting reading that wikipedia link and seeing which anti-patterns I’m currently exhibiting. A lot of this came about as I was writing up a small framework in c++ for iphone prototypes and looking at old code to recall how things were done and whether I should be using a different approach all together.

Vendor lock-in: Making a system excessively dependent on an externally supplied component

This was an unfortunate side-effect of learning objective-c and then going on to write Tilt to Live in objective-c. We’ve been really wanting to expand to other platforms, but with all the code written in objective-c it’s really hard to muster the motivation to rewrite all of it again, especially when solutions that allow you to easily port c/c++ code exist.

Magic pushbutton: Coding implementation logic directly within interface code, without using abstraction.

Another one I’m guilty of, but not entirely sure this is a bad thing in the context of real-time apps. After reading up on mollyrocket’s take on an immediate mode GUI, I’m rather liking the system I have now. It’s not purely immediate mode, but the system I have lets me do some dynamic stuff with the UI that would be a bit harder to do with an ‘abstracted' UI system.

God object: Concentrating too many functions in a single part of the design (class)

My main “game screen” class exhibits this symptom. It came about from evolving my prototype to final production code, which isn’t a good thing most of the time. Looking at the class I can see a lot of classes I can break out to make my life easier, but I’ve just let it sit for the most part. During updates for Tilt to Live I did refactor it a lot so that supporting new gametypes wouldn’t be like gouging my eyes out with a wooden spoon.

Action at a distance: Unexpected interaction between widely separated parts of a system

This one’s a good one because due to “magic push button” and “god object”, fixing bugs tends to create a sorts of anomalies that fall into this category.

Caching failure: Forgetting to reset an error flag when an error has been corrected

I’ve run into this numerous times and it has been the source of many bugs in Tilt to Live. I used object pooling heavily and as a result, when introducing new object types into the mix or new instance variables, forgetting to add them to the reset() method would invariably cause some hiccup in animations, sounds, or even collision.

Lately, I’ve taken time out to start porting some of the framework code I’ve created over the course of Tilt to Live to c++. Having worked pretty much exclusively in objective-c for the past year, I’ve realized how rusty my c++ has become. The main purpose of the rework is so I can have a base for starting new prototypes, as I’m usually stuck with starting from scratch each time. Another benefit is being more “portable”. While developing for android would still require some considerable leg work, the option of going PC, palm, console, or some other device I think is worth it in the long run.