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:
- When you want to save memory. (although this should impact you only when you have tons of numbers to store)
- When you want to force an integral value (e.g., var i: int = j / 2)
- 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.
