Planning Ahead

This may seem obvious to some, but planning ahead is one of the best ways to avoid errors. When you have clearly defined requirements for your project, begin to map out key points of your project, such as the following:

• What version of the Flash player are you going to use? Because different versions of the Flash player support different objects, this is an important question to answer early. You can check which version of the player is required for the different objects in the Help panel (F1).

• How will the data be handled and stored? Understanding your data before you begin to build the application itself is invaluable because it will define the necessary interface pieces required for the users to work with the data.

• Will there be any Object classes that will have to be created? If you know ahead of time that you need to create your own classes or components, you will have more time to figure out what the properties and function of those classes and components will be.

• What are the basic interactions users will have with this project? It may seem harmless to wait until after everything is done before you begin to work on the interactions, but you would be surprised how often minor adjustments to the timing of how users interact with your project can cause errors.

The list can be much larger than that, and sometimes it may have to be. Just remember, the more planning you do in the beginning, the less guesswork you will have to do at the end. Another great way to help plan your project is to build an application flowchart showing every possible path a user can take with every possible outcome.

After you have well-defined requirements, try not to change them. The more changes you make and the more features you add that are outside the scope of the requirements, the more bugs you will have to fix. And after you start creating your project, you can take other steps to shorten debugging.

Names That Make Sense

This has been touched on in earlier chapters, but it's important enough to mention again. When naming things in Flash, give them names that make sense.

Here is an example: Imagine that you have three rectangle buttons on the stage. One is blue and controls the sound volume of your movie. Another is red and controls where in the movie clip a user is. The last button is green and closes the window. You give them the instance names of rec1_btn, rec2_btn, and rec3_btn. Just from reading this paragraph, do you know what the job of rec1_btn is? Of course not, but if they had been named redRec_btn, blueRec_btn, and greenRec_btn, when you code them, or go back to the code at a later time, you would know from the code what the red button does.

And if you are using ActionScript 2.0 in your project, all variable and instance names are case sensitive.

ActionScript 1.0:

 var myVar = "Test"; trace(myvar); //output: Test 

ActionScript 2.0:

 var myVar = "Test"; trace(myvar); //output: undefined 

Documentation

Documenting your code is another great way not only to help prevent unnecessary debugging, but it will also help down the road if you or a colleague needs to revisit the project.

Documenting your code is much harder than it may appear because you don't want to over document your code by putting in comments that are not necessary. For instance, if you set a variable to a specific value, you don't need to document what is being done, but it might be beneficial to document why it is being done. Take the following two pieces of code:

Not helpful:

 //the next line of code sets the X position of rec_mc to 100 rec_mc._x = 100; 

Helpful:

 //the next line of code lines up rec_mc against the picture border rec_mc._x = 100; 

With the second snippet of code, you can clearly see what the horizontal position of rec_mc is being set to, but because of the documentation you can also see why. So if you move the picture, you will know to move rec_mc as well. But the first snippet of code basically documents what you can easily tell from the code, so it is redundant.

Documentation becomes even more important when you're working in teams. If, for instance, you are building several object classes for other developers or designers to use, you have to do more than simply document the code. You have to document what the code will be doing because even with good documentation, not everyone who will have to use your code will understand it. It is also a good idea in your documentation of classes to not only document how something works, but also provide examples that can be copied and pasted in so that your teammates can quickly see how the code will work.

Another great thing to document is version changes. As you fix bugs or add features to your project, document the changes you have made and use some form of incrementing identification so that you can backtrack your changes if you need to. A lot of times, what you do to fix one bug can cause bugs in other areas of your code that were working perfectly in previous versions, so it is important to keep a record of changes.

Strict Data Typing

A great way to catch errors early is to set rules for variables and functions using strict data typing. Introduced with ActionScript 2.0, strict data typing allows you to set the data types of all variables being created like this:

 var myString:String = "David"; 

Then, later in the code, if you were to change the data type of the value in the variable like this:

 myString = 25; 

you would get an error that would look like Figure 17.1 when you either check the code or when you test the movie. This is helpful because if you happen to change data types while in your project, they can be easily found and fixed.

Figure 17.1. An error message is received when the data type of a variable with strict data typing changes.

TIP

Another great feature of strict data typing is that when you data type a variable, code hints for the data type will appear when that variable is used.

You can also use strict data type for functions in two different places. The first is the return value, like this:

 function myFunc():String{         return "test"; } 

If you try to return another data type, or no data type at all, an error will be thrown. If you specifically do not want a return value, you can use Void, like this:

 function myFunc():Void{         //do something, but don't return a value } 

If a value is returned when using Void, an error will be thrown like before. The next parts of a function that can be strict data typed are the parameters. Each parameter can have a separate strict data type without affecting the others, such as this:

 function myFunc(age:Number, theName:String):String{         return theName + " is " + age + " years old."; } trace(myFunc(25, "Ben")); //output: Ben is 25 years old. 

In the preceding example, a function was created with two parameters, age and theName. Both have different strict data types, as does the return value of the function. After the function was created, we tested it with the correct data types to see the output. Go back and put quotes around 25 when we call the function and you will see an error like Figure 17.2 because putting quotes around the number converts it to a string, and that is not the correct data type for that parameter.

Figure 17.2. An error message is sent to the Output panel when a parameter's value does not match its predefined data type.

Strict data typing is a great way to set stricter guidelines on your data and catch errors early on. Another way to catch errors before they accumulate is by prototyping.

Prototyping and Testing

When your project is finally complete, it may have anywhere from 50 lines to well over 20,000 lines of code in it, or more. If you have waited until this point to begin testing and debugging your application, good luck.

Testing should be done throughout the process of building the project in every major browser and in several versions of the Flash player. (For more on testing for the Flash player, see Chapter 7, "Publishing.") And when you test, don't just test for debugging purposes, but also for usability, scalability, as well as other important factors that go into creating a project, such as memory usage and processor performance. And it's at these times that prototyping becomes a valuable asset.

A prototype is a term you may hear in engineering fields, where people building products will create an unfinished working mockup of the product to make sure all the parts work together and that people can use it. Prototyping is the same with Flash projects. Early on, you can quickly build small-scale working versions of what you believe your project will be. This will give you an opportunity to get feedback early on to see if there are any minor issues that can be avoided now before they become major issues later. And Flash is a great tool for prototyping with its built-in component set and easy-to-use data integration features (which are discussed later in this book). An example of prototyping could be that the project will be a database-driven application. Before you begin to connect Flash to the server, use local data to make sure the internal pieces of your project are functioning well; then when you are satisfied that everything works, connect to the server to make your project truly dynamic.

But no matter how much planning and careful coding you do, sooner or later you will have to debug a project; the next section discusses some of the tools used to get the job done.