Confusion and the Art of Programming ActionScript: Style.

How is one to determine which of yesteryear's best practices remain relevant to the world of today, nevermind tomorrow? What, if any, best practices are worthwhile to appropriate from the C/C++ tradition? Or the ActionScript 2 tradition, for that matter?

The prejudice of a guru is manifestly evident in recommendations they might offer, but when responsibly stripped away will (hopefully) reveal sensible and practical (dare I say artful?) wisdom. Worth paying attention to. But when the same recommendation is discovered from a variety of diverse sources, it should probably be followed, or at least not ignored.

Myself, I figure if enough folks, each with experience and knowledge that far exceeds my own, agree that something is the right thing to do, that it probably is. (Precluding any prejudices of my own.)

The world from which I sprang was that of object-oriented C++ graphics programming. My masters and mentors held PhDs in Mathematics and patents (but interestingly, not often both). They were smart folks, but among what wisdom and knowledge they passed down, was that although there is rarely an explicitly right way to do things, there are usually an inifinite number of wrong ways to do something. The goal, as I understand it, is to make the mistake that is likely to incur the least (in volume or intensity) negative consequences. (Hey, I said, just like life.)

Anyway (their response)... is that choosing an option that many reasonable folks agree is pretty good is usually more productive than attempting to develop a better solution -- a task that, when undertaken outside of the algorithmic realm, engineeringly speaking, will almost decisively result in a large amount of wasted time followed by employing the aforementioned reasonable option. I continually strive to develop an ability to accurately discern when to do what is reasonable, and when to listen to my prejudices.

All of this, in fact, belies my prejudice when asking about best practices for ActionScript 3 and Flex 2 (and 3) development. The trouble is that the environment, the interface, the Flash Player client, are so forgiving, that folks with little in the way of wisdom are able to produce fantasticly wonderful work on shear determination, luck, and creative thinking. And certainly, a sloppily-coded application that works wins every time over an artfully-coded one that doesn't, but when they both work, the sloppily-coded app will lose every time if only considering maintenance and extensibility.

See my problem? And it goes well beyond questions of how to interpret an MVC pattern... however it does encompass the definition of what, exactly, a Design Pattern is.

"Programming Style" can be more than just which typeface to use, tabs versus spaces, and how many. Somewhat more significant are issues of brace placement, or whether using a unary operator is a good idea. Then there are deceptively simpler, but I argue, entirely larger issues that have, from what I've seen, been largely, if not entirely, neglected in the Flex2/AS3 dialog.

Is there anything wrong with a long function? Is there anything wrong with multiple, smaller functions when it comes to executing in the Flash Player? Certainly, any inlining is done transparently from the programmer, but how does the Flex2/AS3 community (Adobe developers, that definately means you) justify some of the monsters let loose on the world?

OK, I say to myself, maybe the rule-of-thumb that functions that are too long (in either direction) to fit on a single screen, are probably too complex and should be refactored, doesn't some how apply when it comes to AS3. But that makes no sense, except…

I was extending mx.controls.Button this afternoon, and was surprised at how much was packed into the lowely measure() function or, rather, why it wasn't broken into three-or-four more comprehensible functions. No, it really isn't a complicated thing going on at all, but it could be clearer, and clear and concise source code is just better (or so I've been told).

OK, I say to myself, maybe the rules are different when it comes to AS3 frameworks, so I look at some code for an extended Button class, created by a developer at Adobe. It isn't any better, and in fact, the updateDisplayList() function covers almost three of my ample size screens.

To me, both of those should be refactored... but I can't help wondering what the downside might be of doing such a thing? Some esoteric quality of the Flash Player that might cause function calls to wait until a subsequent rendering pass?

Really. Anyone?

While we're at it, beyond reflecting a legacy, why are private member variables preceeded by an underscore rather than named in a manner that their meaning within the class might be more apparent? Why is it _data and not dataObject?