Adobe's Coding Conventions Leave Me Asking "Why??"

I just took a quick first pass through Adobe’s newly-published Flex Coding Conventions, and while I agree with much of what is in there, a few items leave me scratching my head. 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. By way of a few examples:

Use Array literals rather than new Array().

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 something 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.

Don’t use unnecessary parentheses with common operators such as +, -, *, /, &&, ||, <, <=, >, >=, ==, and !=.

I favor explicit groups, not implicit ones. In my opinion, this: var e:Number = (a * b) / (c + d); is better than this: var e:Number = a * b / (c + d); because it removes ambiguity over whether b is divided by (c + d) or a * b is divided by (c + d).

If the various branches of an if/else statement involve single statements, don’t make them into blocks.

This just makes your code less readable, and introduces an inconsistency in the way the syntax is written. Why have a special case for branches that contain a single statement? This feels more like the personal preference of an experienced developer than a bona fide “best practice” for teams. Indeed, the recommendation for “while” statements is exactly the opposite.

Use int for integers, even if they can’t be negative. Use uint only for RGB colors, bit masks, and other non-numeric values.

Why???? What’s the point in having a uint if you’re only going to use it for things other than unsigned integers?

These are just a few that jumped out at me, because they seemed arbitrary exceptions to the norm. “Best practices” should promote a coding standard that favors minimal variation in syntax over quick coding time, easy understanding over minor performance gains, etc. Overall, I think they’re on the right track – but if they’re going to create all kinds of exceptions to their own rules, they should provide more explanation.

One more – this is just whack:

var a:Array /* of String */ = [];

The language does not support typed arrays. If you need a typed array, extend ArrayCollection and add your own type-checking. Cluttering up your code with comments like this doesn’t offer any compile-time type-checking, and is much less readable than var a:MovieClipArray = new MovieClipArray();

8 Responses to “Adobe's Coding Conventions Leave Me Asking "Why??"”

  1. Dusty says:

    About typed arrays… Adobe did include a metadata tag for compile-time typing of arrays: ArrayElementType, so I don’t know why they wouldn’t use that.

  2. Ryan Guill says:

    about int vs uint, i have always heard that int is an order of magnitude faster in the current flash player, so its always preferable to use int over uint except where necessary.

  3. Pixel Burner says:

    Another comment regarding the uint/int debate -
    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% SLOWER than the int datatype. So, I pretty much never use uint.

    PS – here’s a post by G Skinner regarding the issue:
    http://tinyurl.com/49z8l4

  4. Robert Penner says:

    >> it removes ambiguity over whether b is divided by (c + d) or a * b is divided by (c + d). < <

    Mathematically there is no difference between the two.

  5. tom says:

    The AVM may think so, but at 2 AM my brain is not so sure – and that’s really the point of best practices. It’s easy to forget the execution order:

    trace(6+6/3*3) // 12
    trace(6+6/(3*3)) // 6.666666666666667
    trace((6+6)/(3*3)) // 1.3333333333333333
    trace(6+(6/(3*3))) // 6.666666666666667

    It’s simply easier to predict the outcome when you explicitly define the sub-calculations.

  6. Neo Binedell says:

    The major issue I have with uint in ANY language is that they create very hard to find bugs when they wrap because of casting signed ints or what have you. A rather stupidly simple and visible example:

    var i:int = -1;

    for( var k:unint = i; k < i; k++ )
    doThisForaLooongTime();

  7. Neo Binedell says:

    Bah, thats of course:

    for( var k:uint = 0; k < i; k++ )

  8. Flüge says:

    ehhh, sorry? but where´s here your problem? Is it about the teamwork? In my eyes there is nothing to complaint about, it´s just about learning it. Not the first time in your life, maybe?