The ActionScript 3 compiler is your friend. At least it really wants to be. But some people don’t seem interested in responding to its amicable overtures. No, they’d rather go it alone. However, keeping this clever code-cruncher on-side has its benefits: Problems detected at compile time are far easier to locate and resolve than troublesome runtime errors. So here are my ten top tips to avoid hurting your compiler’s feelings:

1) Never use instances of ‘Object’ for storing data. These are the arch-nemesis of compile time checking. Use them and the compiler won’t event want to know you. They may hold some sentimental value for nostalgic JavaScript coders, but they have no place in Object Oriented software. If you want a hash map or associative array, use a Dictionary. Otherwise, always create your own typed classes - never use an Object as a data bucket.

2) Avoid using references typed as ‘Object’. This is like blind-folding the compiler. If you must work with these, always use a cast before accessing their properties or functions. This gives the compiler the hint it needs (and helps other people understand your code).

3) Don’t use references typed as ‘*’. See above.

4) Never declare your ActionScript classes as dynamic.

5) Beware of Application.application (and other untyped framework properties). The application property of the Application class is somewhat peculiar. It would be reasonable to assume that it is typed as Application, since the instance it points to must be a subclass of Application. Instead it has been typed as ‘Object’, effectively undermining compile-time checking. If you must use it, always put a cast around it to give the compiler the hint it needs:

MyApplication( Application.application ).functionCall();

6) Encapsulate your XML. It may be very handy for exchanging information with a server, but you should avoid using XML as the core data model of an application. Always convert XML to a strongly typed object model when it is received from the server. Passing XML data around inside your application will leave the compiler standing in the corner with nothing to do.

7) Don’t use DynamicEvent.

8) Don’t use mx:Model. It is about as far as your can get from the sort of model you should be creating. As mentioned previously, always create your own typed classes.

9) Don’t use the data property of CairngormEvent. Always subclass CairngormEvent if you need to pass data to a Command.

10) Don’t switch the compiler’s strict mode off!

Comments are closed.