ActionScript 2.0 best practices

ActionScript coding conventions are very important for Macromedia Flash designers and developers to ensure that code and applications are structured in a way that is intuitive and beneficial to themselves as well as other people working on the same project. This is particularly important with long code files. When you follow coding conventions, everyone on the design and development team can understand the code and can work more efficiently. This document helps formalize the ActionScript coding process.

The following guidelines encourage consistency for people learning how to write ActionScript code. Adopt best practices at all times, whether you are a designer or developer, or working alone or as part of a team:

• When you work on ActionScript documents: Adopting consistent and efficient practices helps you speed up your workflow. Additionally, your code is often more portable within the framework of a larger project, and easier to reuse.
• When you share AS files: Other people editing the document can quickly find and understand ActionScript and consistently modify the code.
• When you work on applications: Multiple authors can work on an application with fewer conflicts and greater efficiency.
• When you are learning or teaching ActionScript: Following coding conventions reduces the need to relearn particular methodologies. If students learning ActionScript practice consistent and better ways to structure code, they might learn the language more quickly and with less frustration.

Typically, you spend 80% of your development time debugging, troubleshooting, and practicing general maintenance, especially on larger projects. Even when you work on small projects, you'll spend a significant amount of time analyzing and fixing code. The readability of your code is important for your benefit and the benefit of your team members. When you follow naming conventions, you increase readability, which increases workflow and enables you to find and fix any errors in your code. All programmers follow a standardized way of writing code; this improves the project in many ways.

Using naming conventions for your variable names can serve the following important functions:

• They make your code readable so that you can immediately identify a variable's data type. This can help students, those learning code, or developers unfamiliar with your code.
• They are easy to search for and replace when necessary.
• They help reduce conflicts with reserved words and language constructs.
• They can help you distinguish between variables from different scopes (local variables, class properties, parameters, and so on).

The following sections contain naming guidelines for writing ActionScript code, such as naming files, variables, constants, components, and so on. The section "Formatting ActionScript Syntax" discusses formatting conventions that are specific to ActionScript, and common in other programming languages. The section "ActionScript Coding Conventions" discusses coding conventions that are specific to writing ActionScript and developing with Flash 8.

Note: Flash Player 7 and 8 loosely follow the ECMAScript (ECMA-262) edition 3 language specification. It is useful to see this specification for information on how the language works.

General Naming Guidelines

This section reviews naming guidelines for writing ActionScript code. Naming conventions are important for writing logical code. The primary purpose is to improve the readability of your ActionScript 2.0 code. Remember that all variables must have unique names. Names are case-sensitive in Flash Player 7 and later. Do not use the same name with a different case, because this can be confusing to programmers reading your code and can cause problems in earlier versions of Flash that do not force case sensitivity. Keep the following guidelines in mind when you name items such as variables, files, and classes in Flash:

• Limit your use of abbreviations. Use abbreviations consistently. An abbreviation must clearly stand for only one thing. For example, the abbreviation "sec" might represent "section" and "second."
• Concatenate words to create names. Use mixed-cases (upper and lower case) when you concatenate words to distinguish between each word for readability. For example, select myPelican rather than mypelican.
• Name a file by describing the process or item, such as addUser. Don't use nondescriptive names for methods or variables. For example, if you retrieve a piece of data that is the visitor's user name, you might use the getUserName() method instead of the less descriptive getData() method. This example expresses what is happening rather than how you accomplish it.
• Keep all names as short as possible. Remember to keep names descriptive.

The following sections offer more detail on naming items such as variables, classes, packages, and constants in your code.

Avoiding Reserved Words or Language Constructs

When naming instances and variables, avoid using reserved words, which can cause errors in your code. Reserved words include keywords in the ActionScript language.

Also, do not use any word in the ActionScript 2.0 languages (called a language construct) as an instance or variable name. ActionScript constructs include class names, component class names, method and property names, and interface names.

Warning: Never use different cases to avoid conflicting with reserved words. For example, naming an instance of the textfield TextField class (which doesn't conflict with TextField because Flash is case-sensitive) is a poor coding practice.

Table 1 lists reserved keywords in ActionScript 2.0 that cause errors in your scripts when used as variable names.

Table 2 lists words that are reserved for future use in Flash, from the ECMAScript (ECMA-262) edition 4 draft language specification. Avoid using these words because they might be used in future releases of Flash.

Naming Variables

Variable names can only contain letters, numbers, and dollar signs ($). Do not begin variable names with numbers. Variables must be unique and they are case-sensitive in Flash Player 7 and later. For example, avoid the following variable names:

Use strict data typing with your variables whenever possible because it helps you in the following ways:

• Adds code completion functionality, which speeds up coding.
• Generates errors in the Output panel so you don't have a silent failure when you compile your SWF file. These errors help you find and fix problems in your applications.

To add a data type to your variables, you must define the variable using the var keyword. In the following example, when creating a LoadVars object, you would use strict data typing:

Strict data typing provides you with code completion, and ensures that the value of paramsLv contains a LoadVars object. It also ensures that the LoadVars object will not be used to store numeric or string data. Because strict typing relies on the var keyword, you cannot add strict data typing to global variables or properties within an object or array. For more information on strict typing variables, see About Assigning Data Types and Strict Data Typing in Flash Help or the Flash 8 LiveDocs (Learning ActionScript 2.0 in Flash > Data and Data Types > About Data Types > About Assigning Data Types and Strict Data Typing).

Note: Strict data typing does not slow down a SWF file. Type checking occurs at compile time (when the SWF file is created), not at runtime.

Use the following guidelines when you name variables in your code:

• All variables must have unique names.
• Don't use the same variable name with different cases. Don't use, for example, firstname and firstName as different variables in your application. Although names are case-sensitive in Flash Player 7 and later, using the same variable name with a different case can be confusing to programmers reading your code and can cause problems in earlier versions of Flash that do not force case sensitivity.
• Don't use words that are part of the ActionScript 1.0 or 2.0 language as variable names. In particular, never use keywords as instance names, because they cause errors in your code. Don't rely on case sensitivity to avoid conflicts and get your code to work.
• Don't use variables that are parts of common programming constructs. Don't use language constructs if you are aware of them in other programming languages, even if Flash does not include or support these language constructs. For example, do not use the following keywords as variables:

• Always add data type annotations to your code. Also referred to as "using strict data types with your variables," or "strong typing your variables," adding type annotations to your variables is important in order to:
• Generate errors at compile time so your application doesn't silently fail
• Trigger code completion
• Helps users understand your code

For information on adding type annotations, see About Assigning Data Types and Strict Data Typing in Flash Help or the Flash 8 LiveDocs (Learning ActionScript 2.0 in Flash > Data and Data Types > About Data Types > About Assigning Data Types and Strict Data Typing).

• Don't overuse the Object type. Data type annotations should be precise to improve performance. Use an Object type only when there is no reasonable alternative.
• Keep variables as short as possible while retaining clarity. Make sure your variable names are descriptive, but don't go overboard and use overly complex and long names.
• Only use single-character variable names for optimization in loops. Optionally, you can use single-character variables for temporary variables in loops (such as i, j, k, m, and n). Use these single-character variable names only for short loop indexes, or when performance optimization and speed are critical. The following example shows this usage:

• Start variables with a lowercase letter. Names with capital first letters are reserved for classes, interfaces, and so on.
• Use mixed case for concatenated words. For example, use myFont instead of myfont.
• Don't use acronyms and abbreviations. The exception to this rule is if acronyms or abbreviations represent the standard way to use a term (such as HTML or CFM). For commonly used acronyms, use mixed cases for improved readability, such as newHtmlParser instead of newHTMLParser.
• Use complementary pairs when you create a related set of variable names. For example, you might use complementary pairs to indicate a minimum and maximum game score, as follows:

Naming Constants

You can use constants for situations in which you need to refer to a property whose value never changes. This helps you find typographical mistakes in your code that you might not find if you used literals. It also lets you change the value in a single place.

Variables should be lowercase or mixed-case letters; however, use the following guidelines for naming static constants (variables that do not change):

• Constants should be uppercase.
• Separate words should contain underscores.
• You can see these guidelines at work in the following ActionScript code snippet:

Do not directly code numerical constants unless the constant is 1, 0, or –1, which you might use in a for loop as a counter value.

Naming Boolean Variables

Start Boolean variables with the word "is" (because a Boolean value either "is" or "is not" because of its nature). Therefore, you might use the following for whether a baby is a girl or not (which is a Boolean value):

Or for a variable indicating whether a user is logged in (or not), you might use the following:

Naming Functions and Methods

Use the following guidelines when you name functions and methods in your code. For information on writing functions and methods, see Functions and Methods in Flash Help or the Flash 8 LiveDocs (Learning ActionScript 2.0 in Flash > Functions and Methods).

• Use descriptive names.
• Use mixed case for concatenated words. A good example would be singLoud().
• Start function and method names with a lowercase letter.
• Describe what value is being returned in the function's name. For example, if you are returning the name of a song title, you might name the function getCurrentSong().
• Establish a naming standard for relating similar functions. ActionScript 2.0 does not permit overloading. In the context of object-oriented programming, overloading refers to the ability to make your functions behave differently depending on which data types are passed into them.
• Name methods as verbs. You might concatenate the name, but it should contain a verb. You use verbs for most methods because they perform an operation on an object. Examples of method names include the following:

Naming Classes and Objects

When you create a new class file, use the following guidelines when you name the class and ActionScript file. For proper formatting, see the following examples of class names:

You might have public and private member variables in a class. The class can contain variables that you do not want users to set or access directly. Make these variables private and allow users to access the values only by using getter/setter methods.

The following guidelines apply to naming classes:

• Begin a class name with an uppercase letter.
• Write class names in mixed case when it's a compound or concatenated word.
• Begin with an uppercase letter for a compound or concatenated word. A good example is NewMember.
• Class names are usually nouns or qualified nouns. A qualifier describes the noun or phrase. For example, instead of "member," you might qualify the noun by using NewMember or OldMember.
• Clear names are more important than short names.
• Don't use acronyms and abbreviations. The exception to this rule is if acronyms or abbreviations represent the standard way to use a term (such as HTML or CFM). For commonly used acronyms, use mixed cases such as NewHtmlParser instead of NewHTMLParser for improved readability.
• Use meaningful and simple names that are descriptive of the class contents. To avoid being vague or misleading, use generic names.
• Sometimes a class name is a compound word. A qualifier might describe the noun or phrase. For example, instead of "member," you might qualify the noun using NewMember or OldMember.
• Do not pluralize the words you use in the class name (such as Witches or BaldPirates). In most cases, it is better to leave the words as qualified nouns instead. A qualifier describes the noun or phrase. For example, instead of "cat" or "buckaneer," you might qualify the noun by using BlackCat or OldBuckaneer.
• Don't use a class name in the properties of that class because it causes redundancy. For example, it does not make sense to have Cat.catWhiskers. Instead, Cat.whiskers is much better.
• Don't use nouns that also might be interpreted as verbs. For example, Running, or Gardening. Using these nouns might lead to confusion with methods, states, or other application activities.
• Use unique class names for each class in a single application.
• Do not name classes so that they conflict with the names of built-in classes in Flash.
• Try to communicate the relationship that a class has within a hierarchy. This helps display a class's relationship within an application. For example, you might have the Widget interface, and the implementation of Widget might be PlasticWidget, SteelWidget, and SmallWidget.

For more information on interfaces, see Interfaces in Flash Help or the Flash 8 LiveDocs (Learning ActionScript 2.0 in Flash > Interfaces).

Naming Packages

It's common for package names to use "reverse domain" naming convention. Examples of reverse domain names include com.adobe for adobe.com, and org.yourdomain for yourdomain.org.

• Put the prefix for a package name in all lowercase letters. For example, com, mx, or org.
• Put related classes (classes with related functionality) in the same package.
• Begin package names with a consistent prefix. For example, you might use com.adobe.projectName to maintain consistency. Another example would be com.adobe.docs.learnAS2.Users for the Learning ActionScript 2.0 book in Flash Help.
• Use a clear and self-explanatory package name. It's important to explain the package's responsibilities. For example, you might have a package named Pentagons, which is responsible for using the Flash drawing API to draw various kinds of pentagons in documentation examples; its name would be com.adobe.docs.as2.Pentagons
• Use mixed capitalization for compound or concatenated package names. packageName is an example of a compound, concatenated package name. Remember to use all lowercase letters for the prefix (com, org, and so on).
• Do not use underscores or dollar sign characters.

Naming Interfaces

Starting interface names with an uppercase "I" helps you distinguish an interface from a class. The following interface name, IEmployeeRecords, uses an initial uppercase letter and concatenated words with mixed case, as follows:

The following conventions also apply:

• Interface names have an uppercase first letter. This is the same as class names.
• Interface names are usually adjectives. Printable is a good example.

For more information on interfaces, see Interfaces in Flash Help or the Flash 8 LiveDocs (Learning ActionScript 2.0 in Flash > Interfaces).

Naming Custom Components

Component names have an uppercase first letter, and any concatenated words are written in mixed case. For example, the following default user-interface component set uses concatenated words and mixed case:

• CheckBox
• ComboBox
• DataGrid
• DateChooser
• DateField
• MenuBar
• NumericStepper
• ProgressBar
• RadioButton
• ScrollPane
• TextArea
• TextInput

Components that do not use concatenated words begin with an uppercase letter. If you develop custom components, use a naming convention to prevent naming incompatibilities with Macromedia components. The names of your components must be different from those of the default set that is included with Flash. If you adopt your own consistent naming convention, it helps you prevent naming conflicts.

Remember that the naming conventions in this section are guidelines. It is most important to use a naming scheme that works well for you and to use it consistently.

This section describes how to use comments in your code. Comments document the decisions you make in the code, answering both how and why. For example, you might describe a workaround in comments. Another developer would be able to find the related code easily for updating or fixing. And finally, the issue might be addressed in a future version of Flash or Flash Player, hence the workaround would no longer be necessary.

Writing Good Comments

Using comments consistently in your ActionScript 2.0 code allows you to describe complex areas of code or important interactions that are not otherwise clear. Comments must clearly explain the intent of the code and not just translate the code. If something is not readily obvious in the code, add comments to it.

If you use the Auto Format tool with your code, you will notice that trailing comments move to the next line. You can add these comments after you format your code, or you must modify the comment's new placement after you use the Auto Format tool.

For information on trailing comments, see Trailing Comments in Flash Help or the Flash 8 LiveDocs (Learning ActionScript 2.0 in Flash > Syntax and Language Fundamentals > About Language Punctuators > About Comments > Trailing Comments).

For information on using comments in classes, see the next section, "Adding Comments to Classes."

Use the following guidelines when you add comments to your code:

• Use block comments (/* and */) for multiline comments and single-line comments (//) for short comments. You can also use a trailing comment on the same line as the ActionScript code if necessary.
• Make sure you don't use comments to translate your ActionScript code. You don't need to comment on elements that are obvious in the ActionScript code.
• Comment on elements that are not readily obvious in the code. In particular, add comments when the subject is not described in the surrounding paragraphs.
• Do not use cluttered comments. A line of cluttered comments often contains equal signs (=) or asterisks (*). Instead, use white space to separate your comments from ActionScript code.

Note: If you use the Auto Format tool to format ActionScript, you remove the white space. Remember to add it back or use single-line comments (//) to maintain spacing; these lines are easy to remove after you format your code.

• Remove any superfluous comments from the code before you deploy your project. If you find that you have many comments in your ActionScript code, consider whether you need to rewrite some of it. If you feel you must include many comments about how the ActionScript code works, it is usually a sign of poorly written code.

Note: Using comments is most important in ActionScript code that is intended to teach an audience. For example, add comments to your code if you are creating sample applications for the purpose of teaching Flash, or if you are writing tutorials about ActionScript code.

Adding Comments to Classes

The two kinds of comments in a typical class or interface file are documentation comments and implementation comments.

Note: Documentation and implementation comments are not formally represented in the ActionScript language. However, they are commonly used by developers when writing class and interface files.

You use documentation comments to describe the code's specifications, but not the implementation. You use implementation comments to comment out code or to comment on the implementation of particular sections of code. Documentation comments are delimited with /** and */, and implementation comments are delimited with /* and */.

Use documentation comments to describe interfaces, classes, methods, and constructors. Include one documentation comment per class, interface, or member, and place it directly before the declaration. If you have additional information to document that does not fit into the documentation comments, use implementation comments (in the format of block comments or single-line comments).

Start classes with a standard comment, which uses the following format:

After the documentation comments, declare the class. Implementation comments should directly follow the declaration.

Note: Don't include comments that do not directly relate to the class that's being read. For example, don't include comments that describe the corresponding package.

Use block, single-line, and trailing comments within the body of your class to comment on your ActionScript code.

One of the most important aspects about programming is consistency, whether it relates to variable naming schemes (covered in the earlier section, "Naming Conventions"), formatting code (covered in the later section, "Formatting ActionScript Syntax"), or coding standards and the placement of your ActionScript 2.0 code, which is covered in this section. You dramatically simplify code debugging and maintenance if your code is organized and adheres to standards.

Keeping Your ActionScript Code in One Place

Whenever possible, put your ActionScript 2.0 code in a single location, such as in one or more external ActionScript files or on Frame 1 of the Timeline (when placed on the timeline, the code is called a frame script).

If you put your ActionScript code in a frame script, put the ActionScript code on the first or second frame on the Timeline, in a layer called Actions, which is the first or second layer on the Timeline. Sometimes you might create two layers—an acceptable practice—for ActionScript to separate functions. Some Flash applications do not always put all your code in a single place (in particular, when you use screens or behaviors).

Despite these rare exceptions, you can usually put all your code in the same location. The following are the advantages of placing your ActionScript in a single location:

• Code is easy to find in a potentially complex source file.
• Code is easy to debug.

One of the most difficult parts of debugging a FLA file is finding all the code. After you find all the code, you must figure out how it interacts with other pieces of code along with the FLA file. If you put all your code in a single frame, it is much easier to debug because it is centralized, and these problems occur less frequently. For information on attaching code to objects (and decentralizing your code), see the next section, "Attaching Code to Objects." For more information on behaviors and decentralized code, see the section "Behaviors Conventions" in Flash 8 Best Practices.

Attaching Code to Objects

You must avoid attaching ActionScript code to objects (such as button or movie clip instances) in a FLA file, even in simple or prototype applications. Attaching code to an object means that you select a movie clip, component, or button instance, open the ActionScript editor (the Actions panel or Script window), and add ActionScript code by using the on() or onClipEvent() handler functions.

This practice is strongly discouraged for the following reasons:

• ActionScript code that is attached to objects is difficult to locate, and the FLA files are difficult to edit.
• ActionScript code that is attached to objects is difficult to debug.
• ActionScript code that is written on a timeline or in classes is more elegant and easier to build upon.
• ActionScript code that is attached to objects encourages poor coding style.
• ActionScript code that is attached to objects forces students and readers to learn additional syntax as well as different coding styles that are often poor and limited.
• Users typically have to relearn how to write functions and so on, on a timeline at a later date.

Some Flash users might say it is easier to learn ActionScript by attaching code to an object. Some also say it might be easier to add simple code, or write about or teach ActionScript this way. However, the contrast between two styles of coding (code placed on objects, and frame scripts) can be confusing to developers who are learning ActionScript and should be avoided. Also, users who learn how to write code attached to objects often have to relearn how to place the equivalent code as a frame script at a later date. This is why consistency throughout the learning process, by learning how to write frame scripts, has advantages.

Attaching ActionScript code to a button called myBtn appears as follows. Avoid this method:

Note: However, placing the equivalent ActionScript code on a timeline appears as follows:

For more information, see Syntax and Language Fundamentals in Flash Help or the Flash 8 LiveDocs (Learning ActionScript 2.0 in Flash > Syntax and Language Fundamentals).

Note: Using behaviors and screens sometimes involves attaching code to objects, so different practices apply when you use these features. For more information on behaviors and decentralized code, see the section "Behaviors Conventions" in Flash 8 Best Practices. For more information on screens, see the section "Screens Conventions."

Handling Scope

Scope is the area where the variable is known and can be used in a SWF file, such as on a timeline, globally across an application, or locally within a function. Typically, you can reference scope in more than one way when you write code. Using scope correctly means that you can create portable and reusable ActionScript code, and you don't risk breaking your applications as you build new modules.

It is important to understand the difference between the global and root scopes. The root scope is unique for each loaded SWF file. The global scope applies to all timelines and scopes within SWF files. You use relative addressing rather than references to root timelines, because relative addressing makes your code reusable and portable.

Avoiding Absolute Targets ('_root')

You can use several methods to target instances that let you avoid using _root; these methods are discussed later in this section. Avoid using _root in ActionScript 2.0 because SWF files that load into other SWF files might not work correctly. The _root identifier targets the base SWF file that is loading, not the SWF file using relative addressing instead of _root. This issue limits code portability in SWF files that are loaded into another file, and, particularly, in components and movie clips. You can help resolve problems by using _lockroot, but only use _lockroot when necessary (such as when you are loading a SWF file but do not have access to the FLA file). For more information on using _lockroot, see the next section, "Using _lockroot."

Use this, this._parent, or _parent keywords rather than _root, depending on where your ActionScript 2.0 code is located. The following example shows relative addressing:

All variables must be scoped, except for variables that are function parameters, and local variables. Scope variables relative to their current path whenever possible, using relative addressing, such as the this property. For more information on using the this property, see This Property in Flash Help or the Flash 8 LiveDocs (ActionScript 2.0 Language Reference > ActionScript Language Elements > Global Properties > This Property).

Using '_lockroot'

You can use _lockroot to target content as a way to solve the scoping issues sometimes associated with the inappropriate use of _root. Although this solves many problems with applications, consider _lockroot as a work-around for problems caused by using _root. If you experience problems loading content into a SWF file or a component instance, try applying _lockroot to a movie clip that loads the content. For example, if you have a movie clip called myClip loading content, and it stops working after it is loaded, try using the following code, which is placed on a timeline:

Using the 'this' Keyword

Whenever possible, use the this keyword as a prefix instead of omitting the keyword, even if your code works without it. Use the this keyword to learn when a method or property belongs to a particular class. For example, for a function on a timeline, you write ActionScript 2.0 code by using the following format:

For a class, use the following format to write code:

If you consistently add the this keyword in these situations, your ActionScript 2.0 code will be much easier to read and understand.

About Scope in Classes

When you port code to ActionScript 2.0 classes, you might have to change how you use the this keyword. For example, if you have a class method that uses a callback function (such as the LoadVars class's onLoad method), it can be difficult to know if the this keyword refers to the class or to the LoadVars object. In this situation, you might need to create a pointer to the current class, as the following example shows:

Because you are trying to reference the private member variable within an onLoad handler, the this keyword actually refers to the prodXml instance and not to the Product class, which you might expect. For this reason, you must create a pointer to the local class file so that you can directly reference the class from the onLoad handler.

Structuring a Class File

You create classes in separate ActionScript 2.0 files that are imported into a SWF file when it is compiled.

You create classes in separate ActionScript 2.0 files that are imported into a SWF file when you compile an application. To create a class file, you write code that can have a certain methodology and ordering. This methodology is discussed in the following sections.

The following conventions for structuring a class file show how you can order parts of a class to increase the efficiency and improve the readability of your code.

To structure a class file, use the following elements:

1. Add documentation comments that include a general description of the code, in addition to author information and version information.
2. Add your import statements (if applicable).
3. Write a class declaration, or interface declaration, such as the following:

4. Include any necessary class or interface implementation comments. In this comment, add information that is pertinent for the entire class or interface.
5. Add all your static variables. Write the public class variables first and follow them with private class variables.
6. Add instance variables. Write the public member variables first, and follow them with private member variables.
7. Add the constructor statement, such as the one in the following example:

8. Write your methods. Group methods by their functionality, not by their accessibility or scope. Organizing methods this way helps to improve the readability and clarity of your code.
9. Write the getter/setter methods into the class file.

Guidelines for Creating a Class

Remember the following guidelines when you create a class file:

• Place only one declaration per line.
• Don't place multiple declarations on a single line. For example, format your declarations as shown in the following example:

This example shows better form than putting both declarations on a single line. Place these declarations at the beginning of a block of code.

• Initialize local variables when they are declared. A class's properties should only be initialized in the declaration if the initializer is a compile-time constant.
• Declare variables before you first use them. This includes loops.
• Avoid using local declarations that hide higher-level declarations. For example, don't declare a variable twice, as the following example shows:

This code declares the same variable inside an inner block, which is a practice to avoid.

• Don't assign many variables to a single value in a statement. Follow this convention because otherwise your code is difficult to read, as the following ActionScript code shows:

or

• Make a method or property public only if it needs to be public for a reason. Otherwise, make your methods and properties private.
• Don't overuse getter/setter functions in your class file. Getter/setter functions are excellent for a variety of purposes; however, overuse might indicate that you could improve upon your application's architecture or organization.

  For more information, see About Getter and Setter Methods in Flash Help or the Flash 8 LiveDocs (Learning ActionScript 2.0 in Flash > Classes > About working with custom classes in an application > About getter and setter methods).

• Set most member variables to private unless you have a good reason for making them public. From a design standpoint, it is much better to make member variables private and allow access to those variables through a group of getter/setter functions only.

Using the 'this' Prefix in Class Files

Use the this keyword as a prefix within your classes for methods and member variables. Although it is not necessary, it makes it easy to tell that a property or method belongs to a class when it has a prefix; without it, you cannot tell if the property or method belongs to the superclass.

You can also use a class name prefix for static variables and methods, even within a class. This helps qualify the references you make. Qualifying references makes for readable code. Depending on what coding environment you are using, your prefixes might also trigger code completion and hinting. The following code demonstrates prefixing a static property with a class name:

Note: You don't have to add these prefixes, and some developers feel it is unnecessary. Adobe recommends that you add the this keyword as a prefix, because it can improve readability and it helps you write clean code by providing context.

About Initialization

For the initial values for variables, assign a default value or allow the value of undefined, as the following class example shows. When you initialize properties inline, the expression on the right side of an assignment must be a compile-time constant. That is, the expression cannot refer to anything that is set or defined at runtime. Compile-time constants include string literals, numbers, Boolean values, null, and undefined, as well as constructor functions for the following top-level classes: Array, Boolean, Number, Object, and String. This class sets the initial values of m_username and m_password to empty strings:

Delete variables or make variables null when you no longer need them. Setting variables to null can still enhance performance. This process is commonly called garbage collection. Deleting variables helps optimize memory use during runtime, because unneeded assets are removed from the SWF file. It is better to delete variables than to set them to null. For more information on performance, see the upcoming section, "Optimizing Your Code."

Note: Flash Player 8 has made improvements in garbage collection within Flash Player.

For information on naming variables, see the earlier section, "Naming Variables." For more information on deleting objects, see Delete Statement in Flash Help or the Flash 8 LiveDocs (ActionScript 2.0 Language Reference > ActionScript Language Elements > Statements > Delete Statement).

Note: One of the easiest ways to initialize code by using ActionScript 2.0 is to use classes. You can encapsulate all your initialization for an instance within the class's constructor function, or abstract it into a separate method, which you would explicitly call after the variable is created, as the following code shows:

The following code could be the first function call in the application, and the only one you make for initialization. Frame 1 of a FLA file that is loading XML might use code that is similar to the following ActionScript:

Use 'trace' Statements

Use trace statements in your documents to help you debug your code while authoring the FLA file. For example, by using a trace statement and for loop, you can see the values of variables in the Output panel, such as strings, arrays, and objects, as the following example shows:

This displays the following information in the Output panel:

Using a trace statement is an efficient way to debug your ActionScript 2.0. You can remove your trace statements when you publish a SWF file, which makes minor improvements to playback performance. Before you publish a SWF file, open Publish Settings and select Omit Trace Actions on the Flash tab.

For more information on using a trace, see Trace Function in Flash Help or the Flash 8 LiveDocs (ActionScript 2.0 Language Reference > ActionScript Language Elements > Global Functions > Trace Function).

The Debugger tool is also useful for debugging ActionScript code. For more information, see Debugging Applications in Flash Help or the Flash 8 LiveDocs (Learning ActionScript 2.0 in Flash > Debugging Applications).

About the 'super' Prefix

If you refer to a method in the parent class, prefix the method with super so that other developers know from where the method is invoked. In the following example, you create two classes. You use the super keyword in the Socks class to call functions in the parent class (Clothes). Although both the Socks and Clothes classes have a method called getColor(), using super lets you specifically reference the base class's methods and properties. Create a new AS file called Clothes.as, and enter the following code:

Create a new class called Socks that extends the Clothes class, as shown in the following example:

Then create a new AS or FLA file and enter the following ActionScript in the document:

The following result is displayed in the Output panel:

If you forgot to put the super keyword in the Socks class's getColor() method, the getColor() method could call itself repeatedly, which would cause the script to fail because of infinite recursion problems. The Output panel would display the following error if you didn't use the super keyword:

Avoid the 'with' Statement

One of the more confusing concepts to understand for people learning ActionScript 2.0 is using the with statement. Consider the following code that uses the with statement:

In this code, you attach a movie clip instance from the library and use the with statement to modify its properties. When you do not specify a variable's scope, you do not always know where you are setting properties, so your code can be confusing. In the previous code, you might expect someVariable to be set within the circle1Clip movie clip, but it is actually set in a timeline of the SWF file.

It is easier to follow what is happening in your code if you explicitly specify the variables scope, instead of relying on the with statement. The following example shows a slightly longer, but better, ActionScript example that specifies the variables scope:

An exception to this rule is, when you are working with the drawing API to draw shapes, you might have several similar calls to the same methods (such as lineTo or curveTo) because of the drawing API's functionality. For example, when you draw a simple rectangle, you need four separate calls to the lineTo method, as the following code shows:

If you wrote each lineTo or curveTo method with a fully qualified instance name, the code would quickly become cluttered and difficult to read and debug.

About Using Functions

Reuse blocks of code whenever possible. One way you can reuse code is by calling a function multiple times, instead of creating different code each time. Functions can be generic pieces of code; therefore, you can use the same blocks of code for slightly different purposes in a SWF file. Reusing code lets you create efficient applications and minimize the ActionScript 2.0 code that you must write, which reduces development time. You can create functions on a timeline, in a class file, or write ActionScript that resides in a code-based component, and reuse them in a variety of ways.

If you are using ActionScript 2.0, avoid writing functions on a timeline. When you use ActionScript 2.0, place functions into class files whenever possible, as the following example shows:

Use the following syntax when you create functions:

Avoid using the following syntax, which is difficult to read:

The following example puts functions into a class file. This is a best practice when you choose to use ActionScript 2.0, because it maximizes code reusability. To reuse the functions in other applications, import the existing class rather than rewrite the code from scratch, or duplicate the functions in the new application.

You might use these functions by adding the following ActionScript to your FLA file:

About Stopping Code Repetition

The onEnterFrame event handler is useful because Flash can use it to repeat code at the frame rate of a SWF file. However, limit the amount of repetition that you use in a Flash file as much as possible so that you do not affect performance. For example, if you have a piece of code that repeats whenever the playhead enters a frame, it is processor intensive. This behavior can cause performance problems on computers that play the SWF file. If you use the onEnterFrame event handler for any kind of animation or repetition in your SWF files, delete the onEnterFrame handler when you finish using it. In the following ActionScript 2.0 code, you stop repetition by deleting the onEnterFrame event handler:

Similarly, limit the use of setInterval, and remember to clear the interval when you finish using it to reduce processor requirements for the SWF file.

If you compile a SWF file that contains ActionScript 2.0 with publish settings set to Flash Player 6 and ActionScript 1.0, your code functions as long as it does not use ActionScript 2.0 classes. No case sensitivity is involved with the code, only Flash Player. Therefore, if you compile your SWF file with Publish Settings set to Flash Player 7 or 8 and ActionScript 1.0, Flash enforces case sensitivity.

Data type annotations (strict data types) are enforced at compile time for Flash Player 7 and 8 when you have publish settings set to ActionScript 2.0.

ActionScript 2.0 compiles to ActionScript 1.0 bytecode when you publish your applications, so you can target Flash Player 6, 7, or 8 while working with ActionScript 2.0.

Optimizing Your Code

Remember the following guidelines when you optimize your code:

• Avoid calling a function multiple times from within a loop. It is better to include the contents of a small function inside the loop.
• Use native functions when possible. Native functions are faster than user-defined functions.
• Don't overuse the Object type. Data-type annotations should be precise, because it improves performance. Use the Object type only when there is no reasonable alternative.
• Avoid using the eval() function or array access operator. Often, setting the local reference once is preferable and more efficient.
• Assign the Array.length to a variable before a loop. Assign Array.length to a variable before a loop to use as its condition, rather than using myArr.length itself. For example:

instead of:

• Focus on optimizing loops, and any repeating actions. Flash Player spends a lot of time processing loops (such as those that use the setInterval() function).
• Add the var keyword when declaring a variable.
• Don't use class variables or global variables when local variables will suffice.

Formatting ActionScript 2.0 code in a standardized way is essential to writing maintainable code, and it's easier for other developers to understand and modify. For example, it would be extremely difficult to follow the logic of a FLA file that has no indenting or comments, as well as inconsistent naming conventions and formatting. By indenting blocks of code (such as loops and if statements), you make the code easy to read and debug.

General Formatting Guidelines

When you use spaces, line breaks, and tab indents to add white space to your code, you increase your code's readability. White space enhances readability because it helps show the code hierarchy. Making your ActionScript 2.0 easier to understand by making it more readable is important for students as well as for experienced users working on complex projects. Legibility is also important when you are debugging ActionScript code, because it is much easier to spot errors when code is formatted correctly and is properly spaced.

You can format or write a piece of ActionScript 2.0 code several ways. You'll find differences in the way developers choose to format the syntax across multiple lines in the ActionScript editor (the Actions panel or Script window), such as where you put braces ({}) or parentheses (()).

Adobe recommends the following formatting points to help promote readability in your ActionScript code.

• Put one blank line between paragraphs (modules) of ActionScript.
• Paragraphs of ActionScript code are groups of logically related code. Adding a blank line between them helps users read the ActionScript code and understand its logic.
• Use consistent indentation in your code to help show the hierarchy of the code's structure. Use the same indentation style throughout your ActionScript code, and make sure that you align the braces ({}) properly. Aligned braces improve the readability of your code. If your ActionScript syntax is correct, Flash automatically indents the code correctly when you press Enter (Windows) or Return (Macintosh). You can also click the Auto Format button in the ActionScript editor (the Actions panel or Script window) to indent your ActionScript code if the syntax is correct.
• Use line breaks to make complex statements easier to read. You can format some statements, such as conditional statements, in several ways. Sometimes formatting statements across several lines rather than across a single line makes your code easier to read.
• Include a space after a keyword that is followed by parentheses (()). The following ActionScript code shows an example of this:

• Don't put a space between a method name and parentheses. The following ActionScript code shows an example of this:

or

• Include a space after commas in a list of arguments. Using spaces after commas makes it easier to distinguish between method calls and keywords, as the following example shows:

• Use spaces to separate all operators and their operands. Using spaces makes it is easier to distinguish between method calls and keywords, as the following example shows:

An exception to this guideline is the dot (.) operator.

• Don't include a space between unary operators and their operands. For example, increment (++) and decrement (--), as shown in the following example:

• Don't include spaces after an opening parenthesis and before a closing parenthesis. The following ActionScript code shows an example of this:

• Put each statement on a separate line to increase the readability of your ActionScript code. The following ActionScript code shows an example of this:

• Don't embed assignments. Embedded statements are sometimes used to improve performance in a SWF file at runtime, but the code is much harder to read and debug. The following ActionScript code shows an example of this (but remember to avoid single-character naming in the actual code):

• Assign variables as separate statements. The following ActionScript code shows an example of this (but remember to avoid single-character naming in the actual code):

• Break a line before an operator.
• Break a line after a comma.
• Align the second line with the start of the expression on the previous line of code.

Note: You can control auto-indentation and indentation settings by selecting Edit > Preferences (Windows) or Flash > Preferences (Macintosh), and then selecting the ActionScript tab.

Writing Conditional Statements

Use the following guidelines when you write conditional statements:

• Place conditions on separate lines in if, else..if, and if..else statements
• Use braces ({}) for if statements
• Format braces as shown in the following examples:

When you write complex conditions, it is good form to use parentheses (()) to group conditions. If you don't use parentheses, you (or others working with your ActionScript 2.0 code) might run into operator precedence errors.

For example, the following code does not use parentheses around the conditions:

The following code uses good form by adding parentheses around conditions:

You can write a conditional statement that returns a Boolean value in two ways. The second example is preferable:

Compare this example with the previous one:

The second snippet is shorter and has fewer expressions to evaluate. It's easier to read and to understand.

The following example checks if the variable y is greater than zero (0), and returns the result of x/y or a value of zero (0).

The following example shows another way to write this code. This example is preferable:

The shortened if statement syntax from the first example is known as the conditional operator (?:). It lets you convert simple if..else statements into a single line of code. In this case, the shortened syntax reduces readability.

If you must use conditional operators, place the leading condition (before the question mark) inside parentheses to improve the readability of your code. You can see an example of this in the previous code snippet.

Writing Compound Statements

Compound statements contain a list of statements within braces ({}). The statements within these braces are indented from the compound statement. The following ActionScript code shows an example of this:

Place braces around each statement when it is part of a control structure (if..else or for), even if it contains only a single statement. The following example shows code that is written poorly:

Although this code validates, it is poorly written because it lacks braces around the statements. In this case, if you add another statement after the trace statement, the code executes regardless of whether the numUsers variable equals 0:

Executing the code despite the numUsers variable can lead to unexpected results. For this reason, add braces, as shown in the following example:

When you write a condition, don't add the redundant ==true in your code, as follows:

If you are compare against false, you could use if (something==false) or if(!something).

Writing a 'for' Statement

You can write the for statement using the following format:

The following structure demonstrates the for statement:

Remember to include a space following each expression in a for statement.

Writing 'while' and 'do..while' Statements

You can write while statements using the following format:

You can write do-while statements using the following format:

Writing 'return' Statements

Don't use parentheses with any return statements that have values. The only time to use parentheses with return statements is when they make the value more obvious, as shown in the third line of the following ActionScript code snippet:

Writing 'switch' statements

Follow these rules when writing switch statements:

• All switch statements include a default case. The default case is the last case in a switch statement. The default case includes a break statement that prevents a fall-through error if another case is added.
• If a case does not have a break statement, the case will fall through (see case A in the following code example).

  Your statement should include a comment in the break statement's place, as you can see in the following example after case A. In this example, if the condition matches case A, both cases A and B execute.

You can write switch statements using the following format:

Writing 'try..catch' and 'try..catch..finally' Statements

Write try..catch and try..catch..finally statements using the following formats:

About Using Listener Syntax

You can write listeners for events in several ways in Flash 8. Some popular techniques are shown in the following code examples. The first example shows a properly formatted listener syntax, which uses a Loader component to load content into a SWF file. The progress event starts when content loads, and the complete event indicates when loading finishes.

A slight variation on the first example in this section is to use the handleEvent method, but this technique is slightly more cumbersome. Adobe does not recommend this technique because you must use a series of if..else statements or a switch statement to detect which event is caught.

Where to Go from Here

Changing your workflow to incorporate best practices (or standardizing your code) can take time and patience. However, you will quickly realize the benefits to your code and workflow. If you're just starting to learn ActionScript, use and refer to this guide frequently to help you form good habits as you learn. If you do this, you can avoid having to retrain yourself later on.

For more information about using ActionScript, please see the following resources:

• Flash ActionScript Developer Center
• ActionScript 2.0 and and Object-Oriented Programming articles by Joey Lott (person13.com)
• Flash 8 Best Practices Forum (flash8forums.com: a place for questions, help, suggestions)