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.
