I think it’s always good to cite a source who’s credibility far outreaches your own, I’ve seen many examples of test driven development, implored teams to adopt test driven development, and unit testing in general, and I appreciate how difficult it is for developers to make the change. Developers are after all creatures of habit.

Anyway, I just came across this note within the Subversion development site, dating back to 2001, this is as good a call-to-arms of TDD as I’ve seen, but I think it’s always a good idea to post as many of these as possible…

Many of us implementing the filesystem interface have now gotten into the habit of writing the test cases (see fs-test.c) before writing the actual code. It’s really helping us out a lot — for one thing, it forces one to define the task precisely in advance, and also it speedily reveals the bugs in one’s first try (and second, and third…).

I’d like to recommend this practice to everyone. If you’re implementing an interface, or adding an entirely new feature, or even just fixing a bug, a test for it is a good idea. And if you’re going to write the test anyway, you might as well write it first.

Yoshiki Hayashi’s been sending test cases with all his patches lately, which is what inspired me to write this mail to encourage everyone to do the same. Having those test cases makes patches easier to examine, because they show the patch’s purpose very clearly. It’s like having a second log message, one whose accuracy is verified at run-time.

That said, I don’t think we want a rigid policy about this, at least not yet. If you encounter a bug somewhere in the code, but you only have time to write a patch with no test case, that’s okay — having the patch is still useful; someone else can write the test case.

As Subversion gets more complex, though, the automated test suite gets more crucial, so let’s all get in the habit of using it early.

If you need to do any sort of parameter passing to your AS3 or Flex Swf’s you may be wondering how to do it. In the olden days when you had a _root context on your MovieClips, and thank you very much there were your variables ready and waiting when you loaded your SWF.

Flex / AS3 has a more semantic and structured approach to the problem, well, it puts the values somewhere more semantic and structured at least.

If your application entry point is a subclass of Application you can grab your parameters from MyAppSubclass.application.parameters or in mxml Application.application.parameters.

For example I have a product ID I want to pass to a small swf when I load it.

<mx:Application 
	xmlns:mx="http://www.adobe.com/2006/mxml" 

	creationComplete="initVars()"

	 height="65">
    <mx:Script><![CDATA[
    	
        [Bindable]
        public var productId:String;
        
        // Assign values parameters to properties.
        private function initVars():void {
            productId = Application.application.parameters.productId;
        }
        
    ]]></mx:Script>
    
    <mx:VBox fontSize="18" fontFamily="Arial">
    <mx:HBox>
        <mx:Label text="Product Id: "/>
        <mx:Label text="{productId}" fontWeight="bold"/>
    </mx:HBox>
    </mx:VBox>
</mx:Application>

All I have to do is load the swf with a query string tacked on the end of the swf’s url and supply the key, value pair for my variable.

key: productId
value: 2983127

(or any other product id I need, be careful of invalid strings!)

so the swf load url would look something like…

myflex.swf?productId=2983127

The mxml will run straight from Flex Builder 3 so try it out for yourself and try loading the swf you compile into a browser (without HTML) and put ?productId=THX1138 on the end of the url. The productId will be shown in the SWF.

Naming conventions make programs more understandable by making them easier to read. They can also give information about the function of the identifier-for example, whether it’s a constant, package, or class-which can be helpful in understanding the code In a nutshell it’s about injecting as much meaning into your code as possible, while still remaining terse and concise. I could just suggest you meditate on the phrase, semantic richness.

Packages

The prefix of a unique package name is always written in all-lowercase ASCII letters and should be one of the top-level domain names, currently com, edu, gov, mil, net, org, or one of the English two-letter codes identifying countries as specified in ISO Standard 3166, 1981.

The second part of your top level package should be named after your organisation type, or the organisations name itself, eg. package name tv.simplymedia for simplymedia.tv. then your package begins to describe the code sections themselves, eg. app, view, controller, model etc..

example package names

com.mydomain.app
jp.co.domain.viewer.app
edu.mit.logger

Classes

Class names should be nouns, in mixed case with the first letter of each internal word capitalised. Try to keep your class names simple and descriptive. Use whole words-avoid acronyms and abbreviations, waive this rule if the abbreviation is much more widely used than the long form, such as URL or HTML, in these cases use the form Url, Html etc…

example class names

class Raster {...}
class ImageSprite {...}

Interfaces

Interface names should be capitalised like class names but given a “I” prefix. They should also describe the set of methods (behaviours) which they enforce.

example interface names

interface IDisplayable
interface IStoring

Methods

Methods should be verbs, in mixed case with the first letter lowercase, with the first letter of each internal word capitalized.

example method names

run();
runFast();
getBackground();

Variables

Except for variables, all instance, class, and class constants are in mixed case with a lowercase first letter, subsequent words start with capital letters. Variable names should not start with underscore _ or dollar sign $ characters, even though both are allowed. However private and protected class properties should be prefixed with _(underscore) if they are to be used with public get/set functions.

Variable names should be short yet meaningful. The choice of a variable name should be mnemonic- that is, designed to indicate to the casual observer the intent of its use. One-character variable names should be avoided except for temporary “throwaway” variables. Common names for temporary variables are i, j, k, m, and n for integers; c, d, and e for characters. However, avoid over use of these single letter vars for anything other than iterators.

i:int;
name:String;
baseWidth:Number;

private var _height:Number;

public function get height():Number {
    return _height;
}

public function set height(value:Number):void {
    _height = value;
}

Constants

The names of variables declared class constants should be all uppercase with words separated by underscores (“_”).

public static const MIN_WIDTH:Number = 4;
public static const MAX_WIDTH:Number = 999;

For many years now the Java community have had a broad and clearly defined set of coding standards, for me this was solidified by the Eclipse project, and with the maturing of ActionScript development in the last couple of years, it’s really time the community started to make moves towards a similar standards set.

I propose that a broad based consortium of interested parties should convene on the Java standards and take steps to achieve the following goals.

• Refactor the coding standards applied to Java, for the ActionScript 3.0 language.
• Publish these standards as RFC’s at a prominent community node, ie. osflash.org, Adobe Labs.
• Build certification exams and study guides for the use of student programmers
• Work to build / refine tools to assist development using these standards.

This may seem slightly ambitious, but its important to get something happening here which is larger that any one individual or organisations recognised standard coding practice. Only then can we hope to rely on the coding of accredited developers, and maintain a high quality level industry wide.

I have been and will continue to do what I can to evangelise this standards building process. I would be keen to work with others who feel it’s time to get standards based ActionScript coding up and running.