AS3 Coding Conventions

http://opensource.adobe.com/wiki/display/flexsdk/Coding+Conventions

Some good stuff here. The one thing that bugs me is that this is termed a “Flex” document.

This document lays out the coding standards for writing open-source Flex framework components in ActionScript 3.

But 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 standalone language.

This entry was posted in Flash. Bookmark the permalink.

11 Responses to AS3 Coding Conventions

  1. The bit you quoted pretty much says it all.

    The article is referring to coding conventions used within the AS files that make up the Flex SDK. Someone wishing to submit patches to the SDK would need to follow these conventions in order to get it accepted. While these conventions may be applicable to ActionScript at large, the document is aimed specifically at Flex.

  2. kp says:

    yeah, I get that, but it is an awesome AS3 document. But the title limits it to Flex. It should be released as an AS3 coding conventions document. It’s not just this. Adobe is way to Flex-oriented in my opinion. Way to many classes have Flex dependencies, the whole product “Flex Builder” is named after Flex, but can be used for non-Flex projects. Try to make a non-Flex AIR project in Flex Builder. You can do it, but it’s a hack. Just a pet peeve, as a full time AS3 coder who doesn’t use Flex.

  3. Ryan Taylor says:

    Wow, most of those I actually agree with and currently use. The one that I’m not really comfortable with is event handlers. I still prefer the use of ‘on’ at the beginning of the method handler name. For instance, ‘onMouseDown’ as opposed to ‘mouseDownHandler’ as they suggest.

  4. Tom Lee says:

    I have a few issues with their best practices:

    http://tom-lee.blogspot.com/2008/04/adobes-coding-conventions-leave-me.html

    Maybe I’m just being a bit anal retentive about it – if a developer who worked for me did any one of the things I mention, I wouldn’t take issue with it. But they’re promoting “best practices” here, so they should be held to a higher standard.

    Would love to hear your take on these.

  5. KS says:

    That is pretty sweet, but I would just be happy with an autoformatter for MXML.

  6. kp says:

    I actually agree with you on most of the issues. I used to use uints a lot, but now I’m back to ints, mainly for performance.

    The array commenting seems kind of useless unless you refer back to that line every time you add something to the array, but I thought it might be useful for upgrading your code when typed arrays become available.

  7. Bartek says:

    The array commenting is weird, true.

    One thing I personally do not agree with is the leading “I” when using interfaces. A whole dissertation could be written about why it is bad practice (and another one, by someone, else on why its good I guess).

    The one reason no to use this is when you decide that a class should be transformed into an interface at an advanced stage of a project, adding the leading ‘I’ can mean a lot useless of refactoring. This is how all my interfaces are born – out of simple classes during development.

    A lot of people use interfaces only as “decoration”. Some class can implement an interface but polymorphism is then never used anywhere in the code. The leading “I” only only makes this practice more common.

    I prefer to follow Java guidelines: http://java.sun.com/docs/codeconv/html/CodeConventions.doc8.html. A very good name convention is to have adverbs as interface names: Expandable, Scrollable, Serializable and so on. Of course only whenever it makes any sense.

  8. sascha/hdrs says:

    Some interesting hints there that are new for me and with most I agree. But some are odd: e.g. Switch statements with every case clause as a block … who uses that??

  9. Kevo Thomson says:

    The document lists the abbreviation ‘auto’ twice. Perhaps we should suggest another:

    unred for unnecessarily redundant.

  10. edl says:

    I’ve been looking for something official for a long time as every coder seems to have its own standards of how things should be. Having a guideline from Adobe itself is good yet to a certain point completely useless as there is no explanation of WHY things should be one way vs. the other way, which is kind of frustrating… I’m all for implementing standards for compatibility and what not but I have a difficult time with it when they do not make sense. And some of them really don’t make sense… they probably would if they were explained.

  11. tadster says:

    I’m glad I’m not the only one that thinks some of these “conventions” are bonkers.
    I see the value of typed arrays now that we have vectors. But before vectors I did not see the purpose of a comment stuck right in the middle of my code. And i really don’t get why they suggest using blocks in switch statements, that’s what break; is for!

    Most of it is not bad, just some points seem to be contradicting to normal coding standards. And they never explain WHY we should be following those conventions.

    But, they are going to start calling Flex builder, Flash builder. I think Adobe is waking up to the fact ActionScript is standing up very well as a language on it’s own. Flex has to do with the mxml language and mx packages, this distinction is finally becoming more clear.

Leave a Reply