Adobe Flex Coding Convention Document Triggered Discussions

| by Moxie Zhang Follow 0 Followers on May 08, 2008. Estimated reading time: 3 minutes |

A note to our readers: You asked so we have developed a set of features that allow you to reduce the noise: you can get email and web notifications for topics you are interested in. Learn more about our new features.

On April 18, 2008, Adobe released its Flex SDK coding conventions and best practices. Adobe's Flex Team explained that the new conventions, “. . . lay out the coding standards for writing open-source Flex framework components in ActionScript 3 (AS3). Adhering to these standards makes the source code look consistent, well-organized, and professional.”

Nevertheless, the release has triggered debate among developers in the Flex RIA community. For example, Keith Petters, doesn't like what he sees as a “flex fixation” expressed in the code convention document. He comments, “The one thing that bugs me is that this is termed a Flex document. There is virtually nothing Flex-specific in there. It's all straight AS3 coding conventions. I wish Adobe would get off its Flex fixation and acknowledge the existence of AS3 as a stand-alone language.” Igor Costa responds, “You're right, Keith, when you say that; but, the document as well is only for Flex 4 SDK code guide for ActionScript classes placed on the SDK as well, not the language at all.”

Perhaps, the most active discussions relate to the detailed suggestions on how code should be formatted. As Tom Lee at TL on PL said, “I think it would have been useful for them to offer some sort of rationale behind the recommendations, not just ‘do this, not that' mandates.” For example, Lee takes particular exception with the suggestion to “use Array literals rather than new Array().” He comments:

Isn't "new Array()" more consistent with the way every other kind of object is instantiated? "[]" is a shorthand syntax. I have found shorthand generally to be avoided, because it requires a deeper familiarity with a language than a generalist programmer would possess. I raise the same objection to the recommendations for using Object literals, RegExp literals, and so forth. Consistency is key.

Igor Costa also questions whether the coding conventions and best practices contain some unnecessary dictates. For example, he asks: “Don't put any spaces before or after the left bracket or before the right bracket. Do this: a[0] Not this: a[ 0 ]. Blank spaces are really necessary to worry about it?”

At the same time, Tony Fendall believes consistency and good habits count. He says:

Personally, I agree with the suggested conventions. Yes, you can argue that white spaces are not directly important to the function of the code, but working in code that looks consistent across all classes and functions is much nicer than code where each contributor has his or her own style. The benefits make the task of building a few small habits well worth the effort.

Another discussion focuses on the use of integer and unsigned integer. The coding convention document suggests using int for integers, even if they can't be negative. Use uint only for RGB colors, bit masks, and other non-numeric values. “What's the point in having a uint if you're only going to use it for things other than unsigned integers?” Keith Petters asks.

Pixel Burner observes, “I've noticed that a lot of coders use uint religiously. However, I've read a few articles that suggest that uint can be 200-400 percent slower than the int data type. So, I pretty much never use uint.” Burner also referred to a recent article in Gskinner that specifically talked about the use uint. The article concluded after a coding test:

Avoid uint, unless you have a really good reason for forcing the type. Use ints where they make sense, but don't agonize over the performance implications of int versus Number. Default to Number whenever you aren't sure. Most importantly, don't take things for granted - test and benchmark wherever you can - you might be surprised by the results!

Nevertheless, Sho Kuwamoto of Adobe, strongly suggests avoiding ints in ActionScript, using it only:

    1. When you want to save memory. (although this should impact you only when you have tons of numbers to store)
    2. When you want to force an integral value (e.g., var i: int = j / 2)
    3. To reduce the chance of bugs as you map integral values from client side to server side. (e.g., int fields in value objects).

From all the discussion, one thing is certain. Coding convention involves a whole lot more than just format and maintainability.

Rate this Article

Adoption Stage

Hello stranger!

You need to Register an InfoQ account or or login to post comments. But there's so much more behind being registered.

Get the most out of the InfoQ experience.

Tell us what you think

Allowed html: a,b,br,blockquote,i,li,pre,u,ul,p

Email me replies to any of my messages in this thread
Community comments

Allowed html: a,b,br,blockquote,i,li,pre,u,ul,p

Email me replies to any of my messages in this thread

Allowed html: a,b,br,blockquote,i,li,pre,u,ul,p

Email me replies to any of my messages in this thread


Login to InfoQ to interact with what matters most to you.

Recover your password...


Follow your favorite topics and editors

Quick overview of most important highlights in the industry and on the site.


More signal, less noise

Build your own feed by choosing topics you want to read about and editors you want to hear from.


Stay up-to-date

Set up your notifications and don't miss out on content that matters to you