Situations to avoid when writing ActionScript

Follow these development tips and best practices when developing Adobe Flash Professional projects with ActionScript. This list includes common mistakes that may cause runtime errors or problems that require code debugging. By following these recommendations, you can save time and make your code more extensible.

If you follow a consistent workflow, such as always naming instances as soon as they are added to the Stage, you can eliminate issues that occur when code references cannot find matching instance names (such as undefined errors).

If you get in the habit of naming instances consistently, you'll save time and make the code easier for other developers to update. It's important to choose a naming convention (such as adding a mc_ prefix or a _mc suffix to movie clip instance names) and standardize the names you enter in the instance name field. If you are naming a set of symbol instances that are used to animate a complex object, you may also find it helpful to name the items in a set with the object's name and then the description, like this:

• dog_mouth_mc
• dog_nose_mc
• dog_tail_mc

This practice helps eliminate typos in the project and makes the code easier to understand.

To learn more, read Naming conventions in ActionScript on the Flash Valley site. Also check out the Syntax and Variables sections of the "ActionScript 3 fundamentals" series on the Adobe Developer Connection to learn more about naming conventions.

Additionally, it is critical to avoid using reserved words or beginning instance names with numbers, because these habits can result in programming issues. See the list of reserved words from the O'Reilly book, ActionScript: The Definitive Guide.

ActionScript 3.0 is a case-sensitive language. Identifiers that use lower case instead of upper case are considered different identifiers. For example, the following code creates two different variables in the same script:

The general convention is that class names should begin with a capital letter. Usually, all other names (such as functions, instances, and variables) start with a lowercase letter. If names contain multiple words, all words after the first word in a name can be capitalized (to use camel case for legibility).

While entering instance names, verify that you are typing into the Instance Name field in the Property inspector. If you select an instance by clicking a keyframe in the Timeline, it is a common mistake to accidentally enter its instance name in the Frame Label field instead (see Figure 1).

Many developers add a short notation in their instance names to define them in the code, such as naming movie clips with a mc_ prefix, buttons with a btn_ prefix, and graphic symbols with a gfx_ prefix. You could alternately choose to add suffixes instead, such as naming movie clips with a _mc suffix, buttons with a _btn suffix, and graphic symbols with a _gfx suffix.

You could also choose to capitalize the second word in an instance's name, like this: leftEye_mc and rightEye_mc. This second word capitalization is known as "camel case" because the capital character creates a hump in the middle of the name.

All of these naming conventions are valid. However, it's important to choose one tactic and stick to it for the entire project, to avoid confusion and typos.

Additonally, you can use either underscores or dashes to separate words in a name, such as dog_head or dog-head. You'll find you make less mistakes if you make a conscious decision to always use one or the other, rather than alternating between both in a project.

By choosing your favorite method and standardizing the names you apply to instances, you'll be less likely to encounter errors. This helps eliminate the time-consuming task of scanning the code looking for the mismatch between underscores and dashes.

Take care when writing code to properly reference the names of instances in your project. In addition to avoiding the instance names pitfalls listed above, type carefully to reduce the possibility of introducing typos in properties, events, or methods that can cause runtime errors. For example, when typing the play() method, be sure to add both opening and closing parenthesis. Also watch out for missing quotes and semicolons.

You may find it helpful to click the Check Syntax button (the blue check mark above the Script pane) to make sure there are no syntax errors in the code. Click this option frequently as you add new code. If syntax errors are detected, they are displayed in the Output panel when you test the movie.

Note: It's important to remember that when you check syntax, only the current script in the Actions panel is checked; other scripts that may linked to the FLA file are not checked.

It is often desireable to link your project to external assets. This strategy can make the Flash movie easier to manage and update. However, take care that the paths to the external scripts and graphic elements are correct. If you provide an invalid path to the file, you'll receive an error when you run the SWF file.

Also be careful not to introduce typographical errors when referencing the name of the file. Whenever possible, compare the actual file's name at the time you enter it in Flash to make sure it is spelled correctly.

To learn more, read Loading images and Library assets with ActionScript 3 on the Adobe Developer Connection.

Note: Also be careful to avoid other activities that could cause paths to break, such as moving content to another computer or server or deleting dependent files entirely.

If you choose the option to create an HTML wrapper file in the Publish settings and then publish your project, the resulting files include a folder with the SWF file and the HTML file that contains the code the browser uses to display the SWF file. By default, both the HTML file and the SWF file are exported to the same directory.

Be aware that if you move the HTML file or the SWF file out of the directory where it was generated, the path in the HTML code that links to the SWF file will break. The path will also break if you rename the SWF file. Always test the published movie locally and update the path to the SWF file as needed before uploading the HTML and SWF file to the host server (see Figure 2).

Even if you don't use the loop keyword in your scripts, it is possible to accidentally create code that loops endlessly. Take care to avoid writing infinite loops in functions, because they can crash Flash Player and consume system resources. The while loop example below will continually trace the value of the i variable, which will result in the Output panel displaying an endless series of zeros:

To update this loop so that it resolves after a period of iterations, rather than being endless, add the following line of code below the trace statement inside the curly braces:

After adding this line of code, the value of the variable " i " is incremented, so that the while loop outputs the values 0, 1, 2, 3, 4 and then stops when the < operator compares the value of i and finds that it has become equal to (not less than) 5. Always add a conditional statement to loops. When the condition is met (or is true), the code stops looping.

To learn more about writing loops in ActionScript 3, see the Scripted Loops article on ActionScript.org. Also read the Loops section of the "ActionScript 3 fundamentals" series on the Adobe Developer Connection.

Take care when repurposing third-party code to enter all of the necessary parameters. Follow these guidelines when using code written by someone else:

• ActionScript version: Use ActionScript 3 code when creating an ActionScript 3 project.
• Instance names: Update instance names to match the names of instances in your project.
• External links: Verify that the code snippet does not require other external scripts.
• Attribution: Always leave in comments that identify the original author of the code.

When you create or publish Flash projects, you are prompted to choose the version of ActionScript that the player will interpret. You can either choose ActionScript 3 or ActionScript 2, but not both. If your project contains both types of code, it is likely that the project will have issues when you attempt to run it, because the interpreter will process only a portion of the scripts.

Be especially careful when incorporating third-party code into your projects. Always verify which version of ActionScript a code snippet uses before adding it, to avoid confusion.

When you choose File > New, be sure to select ActionScript 3 as the version in the New Document dialog box when you are developing ActionScript 3 projects. Conversely, if you are using ActionScript 2, be sure to choose that option at the time you create the file (see Figure 3).

Note: When repurposing code from online tutorials and third-party sources, be sure to verify that the ActionScript version matches the version used in your project to avoid mixing ActionScript 2 and ActionScript 3 code in the same FLA file.

Whenever possible, strive to use even values (numbers divisible by two); for instance, dimensions, Stage size, and spacing of elements. This strategy helps keep your code clean and makes it much easier to calculate values when creating functions.

Although it may be tempting to specify a location in the Timeline by its frame number, it is a best practice to create a frame label and reference that location by its frame label name instead. This strategy prevents issues that may occur later when additional frames are added or removed from the Timeline. If you add frame labels, the label names will not change even if the number of frames in the Timeline are adjusted for a project. Additionally, using frame labels as references rather than frame numbers makes the code easier to read.

Here's an example of correct usage of a frame label:

And here's an example of incorrectly specifying a frame number: 

To read more about frame labels, see the Frame label section of the Flash Glossary.

The Output window will display a numeric error number and message if you test a movie that contains runtime errors or compiler errors. These errors often occur when Flash Player is unable to find an object that is referenced or when the code syntax contains errors, including typographical errors or missing symbols, such as parenthesis.

For more details, read the recommendations for fixing runtime and compiler errors on Senocular.com.

To learn more about programming Flash projects with ActionScript, see the following resources:

• ActionScript Technology Center
• Learning ActionScript 3
• ActionScript 3 reference for the Adobe Flash Platform

Refer to Avoiding common authoring mistakes to find links to other articles in this series.