If you think coding conventions are a pain, you probably don’t play nice with others and don’t mind reinventing the wheel every 6 months. Don’t worry, I used to be like you. I thought coding conventions were silly and just got in the way of development. I’m the first to admit that some coding conventions suck (if you don’t know what Hungarian notation is, consider yourself lucky) and should be avoided at all costs. But, the inescapable truth is that a good coding convention makes your code easier to write, maintain and share. They help instantly answer many of the simple questions that come up during your daily coding tasks. They make it easier to come back to old code and understand it, even if you haven’t touched it in a long time. They are the key with which other people can more easily decipher your code.

It’s important to address coding conventions at game poetry because I follow one. The code I post will use this coding convention, because that’s simply how I code. When I write code, I follow this coding convention with very little active thought, so it would actually be more difficult to write code that didn’t follow this coding convention.

If you don’t want to be bothered to read the Urbansquall Coding Conventions (which is funny, given that you could probably work through it in 5 minutes), then I’m going to highlight the most important aspects here:

1. Emulate built-in conventions

The built in ActionScript libraries (particularly for Actionscript 3.0) were designed by people smarter than you and I. Your Actionscript code is forced to play nice with the built-in libraries, so it makes sense to adopt the conventions established by those internal conventions. Emulating the built in libraries will make your code easier to read as the control flow switches from your code to the built in and back. It will also make your code easier to understand for anyone else who eventually needs to work with it.

The implications of this rule in the case of Actionscript 3.0 is that public functions are defined with camel casing, with the first letter being lower cased. Functions generally follow the form verbNoun(), for example addChild() or stopPropagation(). Public properties are camel cased as well, and the first letter is also lower cased, for example scaleX or filters. Class names are Pascal cased with a capital first letter followed by camel casing, for example DisplayObjectContainer or EventDispatcher.

2. Prefix class member variables

This is a coding convention I fought with for the longest time. I swore blind it would damage my code’s readability, and the truth is, it did at first, but only because I was not used to it. After the bumpy orientation, however, I wasn’t even thinking about the prefix anymore and code was just as readable. Not only that, I was spending less time fiddling with variable naming and trying to distinguish local variables from member variables from arguments from seahorses. This is the most important coding convention I have adapted, aside from the inherent convention of emulating built in libraries.

The most common prefixes I’ve seen are _ and m_. At Urbansquall we use m_ and we use it religiously. If you use this convention only 75% of the time, you’re better off not using it at all. C# uses Pascal notation to distinguish public from private properties and that works just fine there. The problem here is that violates our primary coding convention, that of emulating the built in library, and is therefore not ideal.

So, why even bother with prefixes? The main benefit is that it eradicates 99% of naming collisions, which means you save time every time you declare a new variable. It’s impossible for a local variable or an argument to your function to mistakingly interact with a member variable. This makes your code more robust. If you have to create a temporary variable that you will later assign to your member variable, you don’t need to bother coming up with fancy, difficult to comprehend variations on the name, just declare a variable with the same name without the prefix. If your function is taking an argument that gets assigned to a member variable, you don’t need to think of some tricky way to describe the same variable with two names. The prefix implies scope automatically and thus you avoid name collisions, and thus the agonizing about what to name variables and parameters completely.

The other significant advantage is that it also guarantees no naming collisions with public properties. If you decide to expose a member variable via a public property, you never need to do any variable renaming. Simply name the public property the same as the member variable, just without the prefix, and you can move on to the more important task of making an awesome game!

Adjourned

As I mentioned, game poetry source code will be emulating the Urbansquall Coding Conventions. If you have any questions about the extended coding conventions, please ask away. Most of the conventions are attempting to encourage best practices to make code more robust as its written, thus reducing development time and freeing your time up to create a better game.