I am writing this article in the hopes that you will learn from mistakes that I have made. Let me just tell you…sloppy code SUCKS! Once you start getting into bigger projects (or even not such a big project) and even worse when you start to work with others and share code things can become a mess. So I am hoping some of you with no coding standard or no idea of how to “properly” structure your code will get something out of this and decide to do the same or at the least come up with your own standard and stick with it.
Occasionally I do tweak or add to my standards but for the most part I really do keep everything the same.
Currently I’ve been improving some habits of mine (mainly things like spacing and brackets etc) a bit so my older code is a little sloppier than my newer stuff which is okay. I also want to first point out this article by GamePoetry which links to the “UrbanSquall” coding standards. Those are basically what I stick to except for the few additions / changes mentioned below.
So let’s get started.
Class properties / Members
Public
The idea here is to always avoid using getter/setter functions whenever possible. Well, atleast for anything that would be called once or more each frame. If it’s an obscure variable that is rarely called or used for something that isn’t speed related you can use them…otherwise NO. Anything that is both gettable/settable will be simply written as it is:
//it probably wouldn't matter too much if you externally modified this variable
public var maxSpeed:Number;
Read-Only
EDIT ( 12/26/2008 ) : I no longer use different naming convention for read alone variables, I simply either use a getter or I keep them public with a code comment that warns against changing the variable externally.
The speed difference of NOT using getters/setters can be very apparent with something like a “Vector” class where the ‘x/y’ variables are public. This adds probably 20-30 FPS to a demo with about 2-3000 sprites all doing world bounds wrap checks etc. Just imagine the speed difference when ALL of your code complies with this.
Sometimes we may want to reduce the “m_bulletsLeft” safely so in that case create a function such as “shootGun()” inside the class that holds “m_bulletsLeft” rather than making it a public variable and implementing some external code to reduce the “m_bulletsLeft” variable. (This is more of a proper Object Oriented design practice: ‘Encapsulate Change’)
Private / Protected
For all properties usable only by the class that created them we will use: m_variableName
For any protected property which can be used only by classes when extend it we will use: _variableName
//this helps avoid naming conflicts...which is good!
private var m_beanCounter:int;
protected static var _nextID:int = 0;
Naming Conventions
Booleans
Any boolean properties and functions will always be structured in question format. They are followed by the words: “is, has, can, does”:
public var isCollidable:Boolean;
public function doesRayIntersectCircle( a_rayOrigin:Vector, a_rayHeading:Vector, a_circleCenter:Vector, a_circleRadius:Number ):Boolean{ //code }
private var m_hasGun:Boolean;
protected var _canComeToTheParty:Boolean; // lol
Constants
All constants will be in caps with phrases separated by underscores:
public static const HEAVY_ARMOR:int = 0x000001;
public static const WOODEN_SHIELD:int = 0x000010;
public static const SLARGH_FIGHTER:String = "slargh_fighter";
private static const ENEMIES_PER_WAVE:int = 15;
Public Functions / Private Functions
Usually I stick to the “Urbansquall” convention on this which is to use a “verbNoun() format. Sometimes my functions will stray slightly from the “verbNoun” format when parameters are available and instead I will try to complete a sentence with the parameters. In other words I use “verbPreposition(noun)” format:
public function addTo( a_vector:Vector ):void;
public function wrapAround( a_topLeft:Vector, a_bottomRight:Vector):void;
public function dotOf( a_vector:Vector ):Number;
Event Handler Functions
I will treat event handlers slightly different when naming them. I always name them as if they are happening because of an event (hmm…) Which means basically all of them have “on” preceding them.
onScriptLoad(e:Event):void{}
onEntityCollision(e:CollisionEvent):void{}
Variable / Function Positioning
The order I use to place variables and functions ( except for specific circumstances ) are as follows:
- Static Constants
- Getters / Setters
- Public variables
- Constructor
- Public Class Functions
- Overriden Public Functions
- Protected Functions
- Private Functions
- Protected Variables
- Private Variables
As far as I can think of those + the urbanSquall link from above are the conventions I stick with. Hopefully you decide to do the same! Also be sure to read: Better Debug Tracing for some tracing conventions that should be followed as well.