Thursday, April 17, 2008

Here's a New One

This was emitted from a Flex swf I was working on today:

Error: The SystemManager constructor was called when the currentFrame was at 2 Please add this SWF to bug 129782.
at mx.managers::SystemManager()
at _EmbeddingImagesScale9_mx_managers_SystemManager()

Never seen that before. Good times.

Was this post helpful to you? If so, please consider making a small donation to keep this blog going.

Wednesday, April 16, 2008

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();

Was this post helpful to you? If so, please consider making a small donation to keep this blog going.