3 Tips to Help Debug Your Actionscript

It would be a slight understatement for me to say that every once in a while something in Flash doesn’t work. Bugs, errors and other quirks are all too common in Flash development, and learning how to find them quickly is key to being more productive, and learning how to avoid mistakes in the future.

One thing that I have noticed is new Actionscript developers tend to debug by the philosophy:

“If at first you don’t succeed, try again.”

While this might be a great philosophy for many aspects of life, but it just makes you waste time when it comes to debugging your Actionscript. Without proper debugging you have no way of knowing if the code you are changing is actually what is causing the problem.

1) Read and Understand Your Actionscript
The best way to have a good idea of where something might be causing errors is to know your code. If you wrote all of it, you probably have a pretty solid idea of what is going on, but many people use other peoples’ code and just make small changes to it so it suits their needs. In either case, it is always a good idea to read the Actionscript so you understand how its working, what its doing and what different variables are and functions do.

By reading and understanding your code, you might find places where the logic doesn’t flow, or there are typos in variable or function names.

2) Follow the Flow of You Actionscript

As you read through your code, you might read it left to right, top to bottom like a book, which is great for reading, but it’s not how your code usually works. Often it is better to read it in the order it would be executed, which may be difficult if your code is all over the place (a big reason why externalized code is a great thing…but that’s another article), but with a bit more work it is still possible.

If you understand your code, and the idea of what you are trying to make happen, you will find flaws in the order things are executed. For example, if you are trying to animate an element, but you are trying to execute the animation before the element is on the stage, you will obviously have problems getting the animation to happen. By following the flow of your Actionscript, you’ll start to find little errors like this.

If you are unsure of the flow of your Actionscript, you are able to use the debug utility that comes built in with Flash. This utility will allow you to “watch” your code execute. You will be able to see variables change, or even step through and execute code line by line.

The main benefits to points one and two are that when you notice problems during testing you’ll have a very good idea of where to look to fix your problems. The more you learn to read, understand and follow your Actionscript the more you’ll pay attention to the flow of your code while you develop.

3) Well Placed, Descriptive Trace Statements

Knowing when and where to place a trace can be crucial in debugging. When you start putting traces in, it is important to make sure that they are descriptive, so you know what is showing up in your Output panel. Trace statements are valuable when you are not using the debug utility, or if you need a quick debug of something, it is often faster to put a trace in that open up the debug tool. However, in larger projects, you will find that the debug tool is much more helpful than scores of trace statements throughout your code.

The format for a trace is very simple. In the following example, I’d like to make sure that the parent movieclip I am trying to refer to is the one that I think it is, so I’m going to make a trace that tells me what the current movieclip is as well as its parent.

When I test my swf, this could tell me a few things. First, if it shows up, I know that the code is getting executed, which means whatever function the code is in is getting called, or if I have the code on the timeline, the swf plays to that point. Next, it will either tell me the instance name of the current clip and the parent of the clip, which is the information I am looking for in this case.

The most common reasons I find for bugs are:
• Code not being executed
• Variables with incorrect values
• Referring to the wrong movieclip or object

Traces are very helpful in trying to fix all three of the above problems. If your code is not getting executed, put a trace on the frame or function describing what is being executed, or what frame you are at. If you don’t see the trace come up, you know there is something that is preventing your Actionscript from being executed.

Tracing variables is always helpful to ensure that values are being set to them correctly. Sometimes when variables are plugged into mathematical equations, the variables will be undefined. This results in a nice little error in your Actionscript that you would never know about otherwise.

When trying to call functions or methods from other objects or movieclips, sometimes the path used to refer to them is incorrect. The path is when you would put this._parent, or use the instance name of a movieclip, or a series of instance names to refer to another movieclip. Tracing out the path you’ve used to refer to the movieclip will tell you if it’s the right one or not.

Summary
So, in a short and simple way, the three things that will help you debug your code are:
• Having a solid understanding of your Actionscript
• Knowing the order of execution, or flow, of your code
• Placing descriptive trace statements to ensure the accuracy of your variables and path references.

Once you get this stuff down, if your changes don’t work, then its time to keep on trying. You will probably start off with a few ideas to what might be breaking your Actionscript, but if you’ve tried those and its still not working, its time to start back at step number 1.