ActionScript 3.0 coding standards

When authoring the source code for your application, there are several practices that you can use to help keep an application's codebase organized and readable. These will help other developers work on the application later. They can also help you remember how code works if you are required to modify the code in the future.

Best practices for using packages in development

These should be avoided when naming packages. Use pluralized or concept nouns.

The name for a package containing multiple classes should be pluralized, for example, "effects".

For example, if your application contains a collection of custom button classes you could create a package named "customButtons" for them.

For more best practices for packages see Flex best practices – Part 1: Setting up your Flex project. For  additional practices to consider when creating packages, see Flex SDK coding conventions and best practices.
Best practices for classes

Keep the executable code encapsulated in methods.

If the constructor was created to accept arguments and they set instance variables then you should match the argument names to the internal property names.

Class names should be singular objects within your application. Objects should have singular-noun-based  names in UpperCamelCase. For example, if I were writing an online shopping cart system I might name two of the classes ShoppingCart.as and Customer.as. You should also avoid particularly large classes.

For formatter, validator, event, and error related classes append the type of class to the end of the class name. For example, use ServiceConnectionError, ServiceConnectionEvent, ServiceResultsFormatter, and ContactFormValidator.

When creating classes related to skinning, append the type of class to the end of the class name. For example, use SubmitButtonBackground, SubmitButtonBorder, and SubmitButtonIcon.

For class relationships that use inheritance consider appending "Base" to the class name. This can be seen in the Flex framework in classes such as ListBase. This practice is followed when the superclass is considered abstract.

All methods in the class should be separated by a blank line. This increases code scannability and code readability.

If the class you are creating will be part of an inheritance relationship, try to create your class as a concrete representation of an interface. In this context, interface refers to an ActionScript interface, not the user interface.

Best practices for variables

One-character variable names should generally be avoided. Abbreviated variable names should also be avoided.

The compiler will optimize these for you anyway, so the length does not affect file size. Well named variables and functions will make the code easier to read and require the developer to write less documentation.

Try to avoid multiple variable declarations and assignments in a single line of code. Developers can easily overlook a declaration when there are several on a single line.

To improve source code readability, each variable should have an ASDoc comment directly above it; the variable declaration should follow the comment, and a blank line should follow the declaration.

Describe the reasoning for the variable. Try not to restate the purpose of the variable, instead strive to describe how it is used. See the example ASDoc comment in the Commenting ActionScript source code for ASDoc section of this article.

Avoid using "object" in your variable names. Instead, give more meaning to the identifier.

Even if the type is * (no type), strongly typing your variable can help show the intention of the variable. The type can help to convey the variable's use and purpose. A strongly typed variable has a predetermined data type and can contain data of that type only (unless the type is changed).

This practice can help to quickly identify and differentiate the Boolean variables from other variable types; for example: canAnimate, isConnected, or hasChildren.

Constant variables should be in all CAPS with each word separated by an underscore; for example: REMOTE_SERVER_URL, APPLICATION_ID, and DISCLAIMER_TEXT.

Constant variables are values that will not change during the execution of the application. By capitalizing them you can differentiate constants from regular (non-constant) variables.

If the constant is a string, then match the constant variable name to the string contents. For example, the string "dataEvent" should be in a constant variable named "DATA_EVENT".

Prefix variables with an underscore if they will be modified through getter/setter methods.

Best practices for methods

Methods usually perform an action of some kind on an object of some kind. Use the name of the action in the method name; for example, saveUser or parseXML.

Refrain from placing multiple statements on one line.

When possible, group the methods in your classes by responsibility instead of scope. Related methods should be placed together to improve code understandability and readability.

When creating getter/setter methods place the getter method first.

In your comments, explain the reasoning behind the need of the method and describe the usage details for classes that might be calling the method. Explain the "why" instead of restating what the method does. See the example ASDoc comment in the Commenting ActionScript source code for ASDoc section of this article.

Provide a return type for all of your methods. A method's purpose can be better understood by looking at the return type.

Always use an access modifier for method signatures: public, private, protected, internal.

Provide a type for all method arguments. This can help developers as they write code that will call the method.

This helps to differentiate the event handlers from other code in your application. Other standard argument names are e and evt. Like most standards just agree on one way of doing things and stand by it.

Strive for clean, uniform, and standardized source code.

When setting up if, for, case and while statements, place a blank space between the keyword and the parenthesis; for example: while ().

Best practices for formatting

Keep ActionScript classes organized and arranged in a way that is consistent with the rest of the source code throughout your application. This will help later when you or another developer needs to locate a particular area of the code to make a quick change.

You can use the following structure as an example:

1. Initial comment. (Author, version, copyright, code license, and so on).
2. Package declaration
3. Import statements
4. Class-level metadata tags: Event, Style, Effect (with comments!)
5. Class or interface implementation ASDoc comment
6. Class or interface statement

7. Static variables

   1. Public
   2. Protected
   3. Private

8. Instance variables

      
   1. Public
   2. Protected
   3. Private
9. Constructor
10. Getter/setter methods (with backing variables)
11. Methods, grouped according to functionality

Set your editor to insert spaces instead of tabs when you press the Tab key. This will help avoid cross platform source code display and readability issues. Tabs are displayed differently on different operating systems.

Create each method with an ASDoc documentation comment directly above the method. Follow this with the method signature with typed arguments, if arguments are present, then the method body, and finally a blank line.

In general use one space after commas. Use spaces before and after operators such as + and -.

Page 3 of 9

Previous Page

Next Page