Sean is a highly sought after Flex developer and consultant with extensive ActionScript programming experience, including more than five years developing for the Flash platform and over a decade of experience designing and developing desktop and web based applications. Business owner, technical author, blogger and Adobe Flex/AIR enthusiast, Sean is an Adobe Flex Developer Community Champion and the creator of the ActionScript Cheatsheets. Sean has posted 2 posts at DZone. View Full User Profile

Flex best practices – Part 2: Development practices

  • submit to reddit

Flex development best practices review

These practices can be applied to all of your Flex applications. Take a moment to review these practices:

checkmark Create and use an assets directory

checkmark Use subdirectories inside the assets directory

checkmark Use a SWF directory

checkmark Use an images directory

checkmark Use a fonts directory

checkmark Use an audio directory

checkmark Use a video directory

checkmark Use an XML directory

checkmark Don't use verbs, adjectives, or adverbs for package names

checkmark Use plural names for packages

checkmark Name packages according to the classes they contain

checkmark Use classes to promote OOP

checkmark Use nouns for class names

checkmark Minimize the amount of executable code defined in the class body

checkmark Match instance variables to arguments

checkmark Follow the classic general conventions when creating classes

checkmark Append class types (formatter, validator, event, and error) to the class name

checkmark Append the skin type to the class name

checkmark Consider appending "Base" to superclass names

checkmark No spaces in class names

checkmark Use blank lines in between methods

checkmark Code to an interface when possible

checkmark Interface names should be adjectives

checkmark Use meaningful and descriptive variable names

checkmark One variable declaration per line of source code

checkmark Separate each variable declaration with a blank line

checkmark Comment each variable using ASDoc style comments

checkmark Avoid the generic name "object" for variables

checkmark Always strongly type variables

checkmark Prefix Boolean variable names with "can", "is", or "has"

checkmark Capitalize constants

checkmark Match constant string variable names to their contents

checkmark Include a verb in method names

checkmark Limit code to one statement per line

checkmark Group methods in a class by functionality

checkmark Place the getter method above the setter method

checkmark Comment each method using ASDoc style comments

checkmark Always provide a return type even if it is void (returns nothing) or * (any type)

checkmark Always use an access modifier for method signatures

checkmark Specify types for method arguments

checkmark Name the arguments of setter methods "value"

checkmark Name the arguments of event handlers "event"

checkmark Do not use spaces to separate method names from parentheses

checkmark Use blank spaces to separate keywords from parentheses

checkmark Organize ActionScript classes

checkmark Indent each new block of code by four spaces

checkmark Separate each method in a class with a blank line

checkmark Use spaces to improve code readability

checkmark Organize MXML element attributes

checkmark Place the ID attribute as the first attribute for MXML elements

checkmark Group associated attributes together on one line

checkmark Group related attributes for MXML elements

checkmark Place metatags above the property or method that they are marking

checkmark Use blank lines to organize MXML

checkmark Organize MXML documents

checkmark Avoid in-line CSS

checkmark Minimize and clean up your CSS

checkmark Group similar style definitions

checkmark Comment the styles

checkmark Limit CSS declarations to one per line

checkmark Use UpperCamelCase for type selector names

checkmark Use class selectors instead of type selectors when possible

checkmark Use lowerCamelCase for class selector names

checkmark Avoid using underscores in class selector names

checkmark Avoid naming class selectors based on appearance

checkmark Use a consistent naming system

checkmark Follow the standard ASDoc commenting format

checkmark Use white space and leading asterisks to make comments more readable

checkmark Use supported HTML to format the ASDoc output

checkmark Write a complete and concise first sentence of the main description

checkmark Create useful comments for each and every class

checkmark Use @private for hiding classes from ASDoc

checkmark Use @return if the method has a return type

checkmark Use @see for items that have relationships

checkmark Do not use special characters in ASDoc comments

checkmark Comment text should always precede any @ tags

checkmark Describe how the variable will be used

checkmark Create useful comments for all methods and interfaces

checkmark Use fully qualified classpaths for event types

checkmark Create use cases

checkmark Consider using UML

checkmark Consider using code generation

checkmark Consider using design patterns

checkmark Consider using an application development framework

checkmark Use frameworks for team-based development efforts

checkmark Know when NOT to use a framework

checkmark Test behavior instead of testing methods

checkmark Apply the "too simple to break" rule

checkmark Use standard OOP best practices in test cases

checkmark Use clear and concise test method names

checkmark Write simple test case methods

checkmark Use static values in the assertion method calls when possible

checkmark Document the test code

checkmark Create independent unit tests

checkmark Limit assertions to one per test case

Where to go from here

Having delivered multiple presentations on Flex best practices, Ted Patrick offers the following perspective, which I think is applicable to this article as well:

"Every project targeting Flex is different, and thus best practices vary depending on the team involved and the project at hand. I have seen all manner of project practices that work for small teams but fail for larger teams and vice versa. This is my take on Flex best practices from having looked at many projects over the past three years. In many ways, my recommendations should not come as a surprise, as these are tenets of classical software development."

For more information on Flex best practices, see:


Thank you very much to the following people for their input and review of this article. It would not exist without their help: Hong Qiu, Dolores Joya, Jens Chr Brynildsen, Jesse Warden, Ben Dalton, Frederic Cox, Colin Loretz, Jack Wilber and Kai Koenig. (I started getting really interested in programming best practices after reading The Visual Basic Style Guide by Tim Patrick. It's worth a read; check it out if you get the chance.)

Full credit to the sources of inspiration and information for this article:


Published at DZone with permission of its author, Sean Moore.

(Note: Opinions expressed in this article and its replies are the opinions of their respective authors and not those of DZone, Inc.)