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
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
It is common to use a gerund for the name of a package which implements a concept: binding
. Otherwise, they are generally "concept nouns": accessibility
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
, 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();
1.03 File names
var newClass:NewClass = new NewClass();
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
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
1.05 Interface names
Start them with “I” and use intercaps for subsequent words: IList
1.06 Class names
Start them with an uppercase letter and use intercaps for subsequent words: Button
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
Name utility classes FooBarUtil
(not FooBarUtils; the package is plural but the class is singular).
It is common to name a base class FooBarBase
1.07 Event names
Start them with a lowercase letter and use intercaps for subsequent words: "move
1.08 Style names
Start them with a lowercase letter and use intercaps for subsequent words: color
1.09 Enumerated values for String properties
Start them with a lowercase letter and use intercaps for subsequent words: "auto
1.10 Constant names
Use all uppercase letters with underscores between words: OFF
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
public static const FOO_BAR:String = "fooBar";
1.12 Method names
public final class StringUtils
Start them with a lowercase letter and use intercaps for subsequent words: measure()
Method names should always be verbs.
Parameterless methods should generally not be named getFooBar()
; 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()
, 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
mx_internal final function $addChild(child:DisplayObject):DisplayObject
Start them with a lowercase letter and use intercaps for subsequent words: 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 “property”) for a for-in loop variable:
for (var p:String in o)
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.
1.14 Storage variable names
mx_internal final function get $numChildren():int
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:
public function set label(value:String):void
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:
protected function mouseDownHandler(event:Event):void
1.17 Resource bundle names
protected function mouseDownHandler(e:Event):void
protected function mouseDownHandler(evt:Event):void
protected function mouseDownHandler(eventObj:Event):void
If a resource bundle contains resources for a particular package, name the bundle the same as the package: controls
1.18 Resource key names
Start them with a lowercase letter and use intercaps for subsequent words: pm
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: