“Please Mom, can we keep him?”

Remember when you were a little kid and you’d be out playing with your friends and you’d find a stray cat, and he’d follow you home (amazing how cats follow you when you feed them). You would beg and plead with your mom, “Please Mom, can we keep him?” She’d say yes, as long as you promised to take care of it, then you’d go on your merry way. Sometimes it would turn out that the cat was perfect for the family and everyone loved it. Occasionally, that cat you brought home would get into the house and cause all sorts of problems. We had a cat like that, I called it the cat from Hell.

iBrent, what does this have to do with programming? Well, I’ll tell you.

I like to help answer people’s questions about Flash at a number of forums, and often I see posts where they start out by saying: “I found this code on the internet, and…” (“can we keep him?”) then they go on to explain how it doesn’t work, or they don’t know how to adapt it to their project, etc. This is all well and good, accept the problem with Actionscript code is you never know if you have a nice kitty or a cat from Hell.

Do you see the picture now? 😀

Why is it that when we find what looks like helpful code, then bring it home with us, it ends up ruining the furniture? Two reasons:

1. Poor writing. This can be hard to spot especially when we are just starting out in Flash. The problems arise when we want to expand on the existing code, and we run into all sorts of problems because of how it was written. How can we avoid this? Look at who wrote it. Where did you find it? Within a forum? How many posts has the author made? What kind of responses does the author receive? This should give you some indication of what to expect when you want to take that code home and use it in your project.

2. Old Actionscript. This is by far the biggest reason code won’t work, or doesn’t make sense for new Flash users. Most all the cool innovations and features are created with Actionscript 2.0 or higher. Before Macromedia (Adobe) released Actionscript 2.0, everything was referred to as Actionscript. Rarely, if at all do we see a reference within the code to Actionscript 1.0. So we have to do some detective work, and make sure what version of Actionscript we are dealing with. Here is a little checklist I’ve come up with that may help in understanding what version the code is written for. Understanding this will get you a lot further along as you try and adapt it to your work:

a. Check the Date. Most of the code snippets we find online are found in forums or blogs, and most of the time there is a date associated with the post. So, if we know that Actionscript 2.0 was released around September 2003, with the release of Flash Player 7, chances are if the date is pre-2003, it’s Actionscript 1.0.

b. Check for strict data typing. If it’s difficult to determine the date when the post was given, look for strict data typing. In Actionscript 1.0, there is no way to strict data type a variable or object. In Actionscript 2.0 you can, and it looks like this:

var n:Number = 0; or var aList:Array = new Array();

Notice the colon after the var n, and var aList, followed by the data type. This is called strict data typing. It is used by the compiler to check that you haven’t mismatched any data types. (like assigning a number to a string variable)

So, the next time you’re out online playing with your friends and you come across a stray piece of Actionscript code, know what you’re bringing home, before it ruins the furniture! 🙂