I’m collecting useful links for flex developers on del.icio.us/flextools

If you want to send any useful flex development tools or info to the list, add them with your own del.icio.us account and tag them with for:flextools (and anything else useful.)

Thanks.

If you are looking for code formatting tools for Flex Builder, scoot over to https://sourceforge.net/projects/flexformatter/ Ernest Pasour has built an excellent set of source code tools for Flex Builder.

• Code Formatter
• Auto Commenting
• Source Code Reordering

The downloaded zip file can be extracted into the eclipse/dropins folder, and it’ll just work when you restart eclipse. Ernest was also kind enough to provide instructions for source formatting from the command line, so you can format a whole tree of source code at once.

Great for getting your code painlessly adhering to the Flex Coding Conventions.

FlexFormatter also provides a tool for adding asdoc stub comments, (much like my as3dac tool) and should be easy to use for anyone, (admittedly my scripts aren’t for the faint hearted.)

The source code re-ordering tool allows you to re sort the appearance of various parts of a class automatically, constant, constructor, class fields, accessors, mutators and methods all sorted for you effortlessly.

It’s some really great work, and a useful addition to your flex tool set.

(Ernest’s Flex Formatting command line usage guide is here)

Some time ago I scripted an auto commenting system for ActionScript 2.0, I’d long planned to upgrade it to ActionScript 3.0, but things tended to get in the way of that, and I kept putting it off.

I began working on a project recently which needed half a dozen AS3 class libraries to be documented, as luck would have it. So I spent some time updating the scripts from AS2 with NaturalDocs & Doxygen to AS3 with AsDoc.

In a nutshell, the script will parse an AS3 class or interface file and add asdoc comment blocks, it will also adhere to the Flex SDK coding conventions, where there are special cases for doc comments.

Go over to the google code page http://as3dac.googlecode.com and check it out.

If you are using Windows, you’ll need to install Cygwin (with Perl.) You should be able to get going on a Mac, Linux or other *nix. See the code project page for details.

Back in April last year I blogged about coding standards in AS3, I wrote a protracted post covering just naming conventions, and of course there have been numerous posts covering this topic, unfortunately the community rarely agrees on such things, and in particular the genetic strain that builds Flash coders seems to be of a particularly stubborn variety. Of course, I’m just kidding, all developers are stubborn.

Finally, (well back in March, it seems I’m fashionably late to this party.) The Adobe Flex team introduced a set of standards that should be adhered to for contributions to the Flex SDK.

There are a few points which will make widespread adoption of the standards (for use in general.) a little problematic for some developers. The 2 most significant points are these.

The odd Inconsistency.

For a one line if statement, the guidelines stipulate that the following line, after the if, else, elseif, should not be enclosed in { .. } - see below.

// Single command if
if (myCondition)
    trace(myCondition);

// if else with 1 and 2 line commands
if (myCondition)
{
    trace(myCondition);
}
else
{
    i++;
    trace(myCondition);
}

// Single command for loop
for (var i:int = 0; i < n; i++)
{
    trace(i);
}

// Single command while loop
while ( !flag )
{
    trace(flag);
}

Since this pattern doesn’t apply to any other structure, (e.g. for, while etc.) and since it is inconsistency we are fighting when we use code standards, this really shouldn’t be a convention.

Brace wars…

The strategy that must be followed for bracing blocks is aligned braces. For example…

for (var i:int = 0; i < n; i++)
{
    trace(i);
}

This strategy has caused a few AS3 developers to turn a slight shade of blue, I won’t repeat the complaints, they are, I’m sorry to say, redundant. The braces war has raged for far longer than the history of actionscript, and there isn’t a true and right way, both methods have benefits. The Flex team has chosen this strategy, as a professional developer, you should, no, actually, you must follow it.

Just incase you need a bit of rationale, (and trust me, I generally adopted the compressed format prior to the standards announcement.) The opened brace format or BSD style, is beneficial for the following reasons.

• Generally improved readability due to the additional white space.
• Block start and end points, are specifically easier to see due to the uniform alignment of braces with their partner.

There are other benefits but these are the primary ones. Of course you may have contrary opinions about brace style, and of course, so could I, but so what? Follow the standard kiddo.

Notable omission.

There is only one omission that I can think is worth mentioning, it also covers a variety of cases, this is the stipulation that 80 columns should be the maximum line length, it creates a few situations where we have to line break a single statement. The conventions supply a solution to object and array assignment. However, there are a couple of other cases where this could be a problem, method signatures and complex conditional expressions. Without an adequate strategy to cover these cases, we have to rely on the Java standard, which has strategies for handling these cases. It would be better for the Flex conventions to provide a solution.

In conclusion.

The release of a set of comprehensive standards is a necessary move by Adobe, and long overdue, adoption for the wider community is of course not mandatory, but I would expect developers who consider themselves professional to understand the value of adhering to the standards on all but the most trivial of code.

For the developers who wish to contribute to the Flex SDK, it is of course mandatory to follow the standards of the project. I hope that work continues on them at some pace, and that we have a complete and clear set of standards to adhere to in the professional development community.

Naming conventions make programs more understandable by making them easier to read. They can also give information about the function of the identifier-for example, whether it’s a constant, package, or class-which can be helpful in understanding the code In a nutshell it’s about injecting as much meaning into your code as possible, while still remaining terse and concise. I could just suggest you meditate on the phrase, semantic richness.

Packages

The prefix of a unique package name is always written in all-lowercase ASCII letters and should be one of the top-level domain names, currently com, edu, gov, mil, net, org, or one of the English two-letter codes identifying countries as specified in ISO Standard 3166, 1981.

The second part of your top level package should be named after your organisation type, or the organisations name itself, eg. package name tv.simplymedia for simplymedia.tv. then your package begins to describe the code sections themselves, eg. app, view, controller, model etc..

example package names

com.mydomain.app
jp.co.domain.viewer.app
edu.mit.logger

Classes

Class names should be nouns, in mixed case with the first letter of each internal word capitalised. Try to keep your class names simple and descriptive. Use whole words-avoid acronyms and abbreviations, waive this rule if the abbreviation is much more widely used than the long form, such as URL or HTML, in these cases use the form Url, Html etc…

example class names

class Raster {...}
class ImageSprite {...}

Interfaces

Interface names should be capitalised like class names but given a “I” prefix. They should also describe the set of methods (behaviours) which they enforce.

example interface names

interface IDisplayable
interface IStoring

Methods

Methods should be verbs, in mixed case with the first letter lowercase, with the first letter of each internal word capitalized.

example method names

run();
runFast();
getBackground();

Variables

Except for variables, all instance, class, and class constants are in mixed case with a lowercase first letter, subsequent words start with capital letters. Variable names should not start with underscore _ or dollar sign $ characters, even though both are allowed. However private and protected class properties should be prefixed with _(underscore) if they are to be used with public get/set functions.

Variable names should be short yet meaningful. The choice of a variable name should be mnemonic- that is, designed to indicate to the casual observer the intent of its use. One-character variable names should be avoided except for temporary “throwaway” variables. Common names for temporary variables are i, j, k, m, and n for integers; c, d, and e for characters. However, avoid over use of these single letter vars for anything other than iterators.

i:int;
name:String;
baseWidth:Number;

private var _height:Number;

public function get height():Number {
    return _height;
}

public function set height(value:Number):void {
    _height = value;
}

Constants

The names of variables declared class constants should be all uppercase with words separated by underscores (“_”).

public static const MIN_WIDTH:Number = 4;
public static const MAX_WIDTH:Number = 999;