| There's no denying that testing and debugging is part of every programmer's life, but that doesn't mean that it has to be an awful and overwhelming experience. Before we discuss some of the tools that Flash provides to test and debug a project, here are some general guidelines to follow as you build your project: Plan. Don't approach a project until you've created a basic outline of how it should work. You can't reach your end goal if you don't know your final destination. Test everything. Never assume that something works even if it seems a trivial part of your project. All it takes is one mistake to bring your movie to a screeching halt. Test often. Don't wait until your project is nearing completion test at every opportunity. It's much easier to isolate problems if you know your movie was working five minutes ago. Fix bugs in an orderly fashion. Don't attempt to fix a bunch of bugs at the same time. It's best to fix one or two problems at a time and then test after each. After all, you don't want to create any new bugs in the process. Avoid quick fixes. Maybe you're aware that a bug exists, but you're not sure why. In an effort to save time, you may decide to attempt a quick fix or workaround, rather than tracking down the problem. This kind of coding always costs more time in the long run. Take the necessary time to track down the culprit. Comment your code. It's a fact of life: many beginning coders just don't like using comments in their code. They feel that it slows them down, and wastes time. Well, it may seem like a waste of time to comment a project when you first begin coding it. After all, you can typically figure out what your code is doing by simply glancing at it. Start adding several hundred or even several thousand lines of code, however, and your attitude will quickly change. Comments provide the means for you to detail in human terms what a particular piece of code is doing. This can be a great help as the number of lines of code in your project increases. A useful technique is to comment before you start writing any code. This forces you to think about the problem (breaking it down into commented steps) before diving into it. Know when to step away. Few things are as frustrating as knowing that something should work, but yet it doesn't. In an attempt to resolve these problems, it's easy to lose track of time, forget to eat, or even forget that you have friends and family. Instead of doing all this forgetting, step away for awhile, refresh yourself, and return to the bug-squashing process a little later. Sometimes, all it takes to locate a nagging problem is to recharge your batteries.
Okay, so you've approached your project with a well-defined plan, used comments and a standard naming convention, and double-checked all your code but you still have a project that's just not working properly. What can you do? The remainder of this lesson will deal with that question. |
