Guidelines for ActionScript - Naming Guidelines

Published on
9,440 Points
Last Modified:
Community Pick
I have been doing hardcore actionscripting for some time; and needless to say I have faced a lot of problems in just understanding others' code rather than understanding what the code executes. A programmer's life can become hell when there are a lot of developers working together in a team without a consistent framework for terminology.

Each developer uses his/her own way of coding which adds to the complexity in understanding code rather than what the code actually performs. In such scenarios, a guideline will always help a team to work without getting confused on what others have coded previously. From my experience and learning from different articles, I have tried to set up some coding guidelines for any type of ActionScript projects; these guidelines have helped me in my projects till now. The coding standard will help to streamline the Flash/Flex development structure and will lean to better performance of RIA projects. The coding guidelines should be used by any developer doing ActionScript coding.

1.01    Package Names
Start them with a lowercase letter and use intercaps for subsequent words: controls, listClasses.

Package names should always be nouns or gerunds (the -ing noun form of a verb), not verbs, adjectives, or adverbs.

A package implementing lots of similar things should have a name which is the plural form of the thing: charts, collections, containers, controls, effects, events, formatters, managers, preloaders, resources, skins, states, styles, utils, validators.

It is common to use a gerund for the name of a package which implements a concept: binding, logging, messaging, printing. Otherwise, they are generally "concept nouns": accessibility, core, graphics, rpc.

Eg: A package containing classes that support component FooBar should be called fooBarClasses.

1.02    Type-specifying names
If you want to incorporate the type into the name, make it the last “word”. Don't use the old ActionScript 1 convention of concatenating abbreviated type suffixes such as _mc to indicate type. For example, name a border Shape border, borderSkin, or borderShape, but not border_mc.

Often, the best name for an object is simply the same as its type, with different casing:  
var button:Button = new Button();

Open in new window

var newClass:NewClass = new NewClass();

Open in new window

1.03    File names
For importable APIs, the file name must be the same as the public API inside. But include files don't have to follow this rule.

Start the names of include files for [Style(...)] metadata with an uppercase letter, use intercaps for subsequent words, and make the last word “Styles”: BorderStyles.as, ModalTransparencyStyles.as.

Start the names of individual asset files with a lowercase letter and use underscores between words: icon_align_left.png.

1.04    Namespace names
Start them with a lowercase letter and use underscores between words: mx_internal, object_proxy.

1.05    Interface names
Start them with “I” and use intercaps for subsequent words: IList, IFocusManager, IUID.

1.06    Class names
Start them with an uppercase letter and use intercaps for subsequent words: Button, FocusManager, UIComponent.

Name Event subclasses FooBarEvent.

Name Error subclasses FooBarError.

Name the EffectInstance subclass associated with effect FooBar FooBarInstance.

Name Formatter subclasses FooBarFormatter.

Name Validator subclasses FooBarValidator.

Name skinning classes FooBarBackground, FooBarBorder, FooBarSkin, FooBarIcon, FooBarIndicator, FooBarSeparator, FooBarCursor, etc.

Name utility classes FooBarUtil (not FooBarUtils; the package is plural but the class is singular).

It is common to name a base class FooBarBase, ComboBase, DateBase, DataGridBase, ListBase.

1.07    Event names
Start them with a lowercase letter and use intercaps for subsequent words: "move", "creationComplete".

1.08    Style names
Start them with a lowercase letter and use intercaps for subsequent words: color, fontSize.

1.09    Enumerated values for String properties
Start them with a lowercase letter and use intercaps for subsequent words: "auto", "filesOnly".

1.10    Constant names
Use all uppercase letters with underscores between words: OFF, DEFAULT_WIDTH.

The words in the identifier must match the words in the constant value if it is a String:
public static const FOO_BAR:String = "fooBar";

Open in new window

1.11    Use final when no subclasses need to be created of a class
public final class StringUtils

Open in new window

1.12    Method names
Start them with a lowercase letter and use intercaps for subsequent words: measure(), updateDisplayList().

Method names should always be verbs.
Parameterless methods should generally not be named getFooBar() or setFooBar(); these should be implemented as getter/setters instead. However, if getFooBar() is a slow method requiring a large amount of computation, it should be named findFooBar(), calculateFooBar(), determineFooBar(), etc. to suggest this, rather than being a getter.

If a class overrides a method and wants to continue to expose the base method, it should do so by implementing a method whose name is the base name with a $ prepended. This method should be marked final and should do nothing more than call the supermethod.
mx_internal final function $addChild(child:DisplayObject):DisplayObject
    return super.addChild(child);

Open in new window

1.13    Property (variable and getter/setter) names
Start them with a lowercase letter and use intercaps for subsequent words: i, width, numChildren.

Use i for a loop index and n for its upper limit. Use j for an inner loop index and m for its upper limit.
for (var i:int = 0; i < n; i++)
    for (var j:int = 0; j < m; j++)

Open in new window

Use p (for “property”) for a for-in loop variable:
for (var p:String in o)

Open in new window

If a class overrides a getter/setter and wants to continue to expose the base getter/setter, it should do so by implementing a property whose name is the base name with a $ prepended. This getter/setter should be marked final and should do nothing more than call the super getter/setter.
mx_internal final function get $numChildren():int
    return super.numChildren;

Open in new window

1.14    Storage variable names
Give the storage variable for the getter/setter foo the name _foo.

1.15    Event handler names
Event handlers should be named by concatenating “Handler” to the type of the event: mouseDownHandler().

If the handler is for events dispatched by a subcomponent (i.e., not this), prefix the handler name with the subcomponent name and an underscore: textInput_focusInHandler().

1.16    Argument names
Use value for the argument of every setter:
Right usage:
public function set label(value:String):void

Open in new window

Wrong usage:
public function set label(lab:String):void
public function set label(val:String):void
public function set label(labelValue:String):void

Open in new window

Use event (not e, evt, or eventObj) for the argument of every event handler:

Right usage:
protected function mouseDownHandler(event:Event):void

Open in new window

Wrong usage:
protected function mouseDownHandler(e:Event):void
protected function mouseDownHandler(evt:Event):void
protected function mouseDownHandler(eventObj:Event):void

Open in new window

1.17    Resource bundle names
If a resource bundle contains resources for a particular package, name the bundle the same as the package: controls, {formatters}}, validators.

1.18    Resource key names
Start them with a lowercase letter and use intercaps for subsequent words: pm, dayNamesShort.

My coding guidelines are based in part on Adobe's framework, and in work others have done. Some further reading (including sources I drew upon) are below:

Reference Articles
Ask questions about what you read
If you have a question about something within an article, you can receive help directly from the article author. Experts Exchange article authors are available to answer questions and further the discussion.
Get 7 days free