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

03.16.2009
| 50606 views |
  • submit to reddit

ActionScript 3.0 coding standards

When authoring the source code for your application, there are several practices that you can use to help keep an application's codebase organized and readable. These will help other developers work on the application later. They can also help you remember how code works if you are required to modify the code in the future.

Best practices for using packages in development

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

These should be avoided when naming packages. Use pluralized or concept nouns.

checkmark Use plural names for packages

The name for a package containing multiple classes should be pluralized, for example, "effects".

checkmark Name packages according to the classes they contain

For example, if your application contains a collection of custom button classes you could create a package named "customButtons" for them.

For more best practices for packages see Flex best practices – Part 1: Setting up your Flex project. For  additional practices to consider when creating packages, see Flex SDK coding conventions and best practices.

 

Best practices for classes

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

Keep the executable code encapsulated in methods.

checkmark Match instance variables to arguments

If the constructor was created to accept arguments and they set instance variables then you should match the argument names to the internal property names.

checkmark Follow the classic general conventions when creating classes

Class names should be singular objects within your application. Objects should have singular-noun-based  names in UpperCamelCase. For example, if I were writing an online shopping cart system I might name two of the classes ShoppingCart.as and Customer.as. You should also avoid particularly large classes.

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

For formatter, validator, event, and error related classes append the type of class to the end of the class name. For example, use ServiceConnectionError, ServiceConnectionEvent, ServiceResultsFormatter, and ContactFormValidator.

checkmark Append the skin type to the class name

When creating classes related to skinning, append the type of class to the end of the class name. For example, use SubmitButtonBackground, SubmitButtonBorder, and SubmitButtonIcon.

checkmark Consider appending "Base" to superclass names

For class relationships that use inheritance consider appending "Base" to the class name. This can be seen in the Flex framework in classes such as ListBase. This practice is followed when the superclass is considered abstract.

checkmark Use blank lines in between methods

All methods in the class should be separated by a blank line. This increases code scannability and code readability.

checkmark Code to an interface when possible

If the class you are creating will be part of an inheritance relationship, try to create your class as a concrete representation of an interface. In this context, interface refers to an ActionScript interface, not the user interface.

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