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

Part 1 of this series focused on best practices for setting up your Flex projects. In Part 2, I continue the discussion by outlining best practices to use during the Flex development process. This article contains over 90 best practices for the Flex development process!

In this article, you will learn how to manage assets so that your application's dependencies will be well organized. I will also discuss widely accepted ActionScript 3.0, MXML, and CSS coding standards currently being practiced by the Flex development community. I'll review ASDoc, a tool that you can use to create API language reference documentation as HTML from your application's source code. In the application architecture section of this article I'll show techniques that you can use to help define the blueprints for your application's foundation. I will cover some of the application development frameworks that are available to Flex developers and discuss when it makes sense to use them and when it does not. Lastly, I will cover best practices for unit testing so that you can test your codebase and ensure the code will perform consistently.

Following these best practices will help you navigate and scale an application's codebase with speed and ease, rather than aimlessly traversing through source code and constantly adding ad hoc fixes.

Let's get going!


In order to make the most of this article, you need the following software:

Flex Builder 3

If you are willing to sacrifice the powerful tool set provided by Flex Builder 3.0 standalone or plug-in, applications can be developed using only the Flex 3 SDK.

The practices covered in this article should be followed regardless of which setup you use.


Basic familiarity with ActionScript 3.0 and Flex is needed to understand this article. Experience with object-oriented programming (OOP) will also help you to understand the concepts and practices set forth in this article.


Handling assets

Flex applications typically incorporate a collection of files, including several different types of media, such as images, CSS files, fonts, audio clips, and video, to name a few. Keeping the application's assets and source code organized can save time when requests to change the software later surface. Here are some general guidelines to consider when naming and storing the files associated with your Flex application.

checkmark Create and use an "assets" directory

The common best practice is to create a folder titled "assets" and store it inside the src directory. The src directory is created by Flex Builder during the Flex project setup.

Thus, the root of your asset directory path will be: src/assets

checkmarkUse subdirectories inside the assets directory

To help organize the many type of media your application can use, I recommend that you organize subdirectories logically based on the types of media files in use. The following points highlight some commonly used practices for subdirectories.

checkmarkUse a SWF directory

Consider keeping the SWF files in your Flex application stored in a directory named "SWF".  You may want to use a different directory depending on the purpose of the SWF files being loaded into the application. Modules, for example, may be kept elsewhere. Modules are beyond the scope of this article but more information can be found here: Writing modules.

The SWF directory path will be: src/assets/swf

checkmark Use an images directory

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.)