InfoQ

News

Adobe Flex Coding Convention Document Triggered Discussions

Posted by Moxie Zhang on May 08, 2008 09:20 AM

Community
Java
Topics
Rich Internet Apps
Tags
Flex

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.

No comments

Reply

Exclusive Content

Tapestry for Nonbelievers

A new article by I. Drobiazko and R. Zubairov introduces v. 5 of the Apache Tapestry component-oriented web framework. The tutorial shows how to create a component and covers IoC in Tapestry and Ajax.

Pete Lacey on REST and Web Services

In this interview, Burton Group consultant Pete Lacey talks to Stefan Tilkov about his disillusionment with SOAP, his opinion on REST, and addresses some of the perceived shortcomings REST vs. WS-*.

Business Natural Languages Development in Ruby

Jay Fields presents his concept of Business Natural Languages - a type of Domain Specific Languages geared towards being readable by domain experts.

Distributed Version Control Systems: A Not-So-Quick Guide Through

Adoption and interest for Distributed Version Control Systems is constantly rising. We will introduce the concept of DVCS and have a look at 3 actors in the area: git, Mercurial and Bazaar.

Segundo Velasquez and Agile as Seen Through the Customer's Eyes

Deborah Hartmann interviewed Segundo Velasquez about his experience as customer with an Agile team during the initial phase of software design of a product.

Fine Grained Versioning with ClickOnce

David Cooksey shows how to fine grained versioning to a ClickOnce deployment using an HttpHandler written with ASP.NET, making partial rollouts to a test audience much easier.

Implementing Manual Activities in Windows Workflow

Windows workflow (WF) is an excellent framework for implementing business processes, but lacks support for human activities. This article describes a completely generic approach for changing this.

Markus Voelter about Software Architecture Documentation

In this interview taken during OOPSLA 2007, Markus Voelter talks about the importance of documenting the software architecture, and gives some good and also bad examples on how it could be done.