Browse All Articles > Guidelines for ActionScript - Naming Guidelines
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:
Eg:
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:
1.11 Use final when no subclasses need to be created of a class
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.
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.
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:
Wrong usage:
Use event (not e, evt, or eventObj) for the argument of every event handler:
Right usage:
Wrong usage:
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
http://livedocs.adobe.com/flex/2/langref/statements.html
http://livedocs.adobe.com/flex/3/html/help.html?content=asdoc_3.html
http://livedocs.adobe.com/flash/9.0/ActionScriptLangRefV3/Array.html
http://www.adobe.com/devnet/actionscript/articles/oop_as3.html
http://www.actionscript.org/resources/articles/684/1/Object-Oriented-Programming-in-AS3/Page1.html
http://oddhammer.com/actionscriptperformance/set4/
http://www.craftymind.com/2008/11/20/max-2008-session-material/
http://www.rozengain.com/blog/2007/05/01/some-actionscript-30-optimizations/
http://www.lostinactionscript.com/blog/index.php/2008/09/28/tips-on-how-to-write-efficient-as3/
http://www.adobe.com/devnet/flex/articles/client_perf.html
http://www.stephencalenderblog.com/?p=7
http://www.gskinner.com/blog/archives/2006/06/types_in_as3_in.html
http://www.adobe.com/devnet/flashplayer/articles/resource_management.html
http://agit8.turbulent.ca/bwp/2008/08/04/flash-as3-optimization-fastest-way-to-copy-an-array/
http://blog.andre-michelle.com/2005/as3-optimations-suggestions/
http://www.ericfeminella.com/blog/2008/05/06/package-level-function-closures-in-actionscript/
http://blog.joa-ebert.com/2008/04/26/actionscript-3-optimization-techniques/
http://businessintelligence.me/projects/performance_tester/performanceTester.html
http://www.betaruce.com/blog/?p=65
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();
Eg:
var newClass:NewClass = new NewClass();
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";
1.11 Use final when no subclasses need to be created of a class
public final class StringUtils
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);
}
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++)
{
...
}
}
for (var p:String in o)
{
...
}
mx_internal final function get $numChildren():int
{
return super.numChildren;
}
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
Wrong usage:
public function set label(lab:String):void
public function set label(val:String):void
public function set label(labelValue:String):void
Use event (not e, evt, or eventObj) for the argument of every event handler:
Right usage:
protected function mouseDownHandler(event:Event):void
Wrong usage:
protected function mouseDownHandler(e:Event):void
protected function mouseDownHandler(evt:Event):void
protected function mouseDownHandler(eventObj:Event):void
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
http://livedocs.adobe.com/
http://livedocs.adobe.com/
http://livedocs.adobe.com/
http://www.adobe.com/devne
http://www.actionscript.or
http://oddhammer.com/actio
http://www.craftymind.com/
http://www.rozengain.com/b
http://www.lostinactionscr
http://www.adobe.com/devne
http://www.stephencalender
http://www.gskinner.com/bl
http://www.adobe.com/devne
http://agit8.turbulent.ca/
http://blog.andre-michelle
http://www.ericfeminella.c
http://blog.joa-ebert.com/
http://businessintelligenc
http://www.betaruce.com/bl
Have a question about something in this article? You can receive help directly from the article author. Sign up for a free trial to get started.
Comments (0)