The trace() Statement—Respect, Responsibility and Solutions

Posted on July 30, 2007 by Tuesday Creative
Industry, Tech

The trace() Statement – Respect, Responsibility and Solutions

Part 1 - Respect.

The trace() statement is the most valuable of all the global functions in Actionscript. Period.

The trace() function in Actionscript sends text messages to a console. That’s all it does. Really. And it’s still the most valuable tool in the Actionscript toolbox. Here’s why:

  1. Debugging is by far the most important step of the software design life cycle.
  2. Computers don’t decide to misbehave they do exactly as they are told. If software developers were perfect, everything they wrote would perform exactly as expected without bugs, errors or mysteries. That never happens. Even if one developer is perfect, the software he or she writes is dependent on software written by companies (Adobe, Apple), organizations (Mozilla, GNU) and colleagues (other developers at work, the open-source community) that may not be perfect, and therefore may have bugs.
  3. Essentially, all bugs come from the same source—developers telling machines to do the wrong things by making incorrect assumptions.
  4. In any program the machine is making thousands of calculations and decisions per second about everything from what to color a background with to how many lives a gamer has left. Trace() gives you the ability to examine the inner workings of the machine and see if your assumptions about how it makes decisions are correct. If you have zero insight on how the machine is making decisions, you are blindly trusting that you, and every developer before you, is perfect. A tool this useful, however, should be wielded properly.

Part 2 - Responsibility.

trace() is one of the first things any Actionscript developer learns. Consequently, many developers have developed some very sloppy habits when it comes to using trace(). Anyone who has the Debug Flash Player installed (this includes pretty much every developer and designer in the world that uses MTASC, Eclipse, Flex Builder, mxmlc, or any Actionscript development tool other that the Flash IDE) can and will see any trace()messages you leave in your application or website. Believe me, we know which sites do it and which ones do not.

Console output should be considered another layer of presentation in your application with an audience and a designed message. I saw one example of an industrial designer echoing the main messaging of each product in the console. I have to admit I was very impressed.

The following list is just a few things off the top of my head that I’ve seen over the years. All parties will remain nameless, of course, as I’m not here to make any particular developer look bad. I’m here to help people learn to develop better.

Spamming the console
This is by far the most common example of irresponsible behavior I’ve seen. Anyone who has the debug player installed should know what happens when they visit almost any website. A deluge of messages pours into their console. Even a postage-stamp-sized flash banner can generate hundreds of lines of useless output per second in the hands of a sloppy developer. In fact, I am unable to use any instant messenger program that contains flash ads because the output mixes in with mine while I’m trying to work. Any developers out there who have tried to work and use AIM Triton simultaneously? It’s impossible. Additionally, there is a point where overflowing the console actually slows the program down.

Assuming your output is secret
A flash racing game for a major auto manufacturer had plenty of output for me to read as I waited for the game to load. While scrolling through it, I realized that they had listed every asset loading into the game. These assets were all in hidden folders on the automaker’s website. Interestingly, the game used some files outside of its own directory in other areas of the auto maker’s site so anyone who looked at their console had extensive knowledge of the server structure and could choose to lift any of the copyrighted music, images, video and whatever else their prying eyes wanted to find. I’m sure the car company did not intend for whoever developed their game to expose their server structure.

Using inappropriate messages
I recall one freelance designer that was doing a website for a movie starring a particular actress he had a low opinion of. He inserted some colorful messages into his output and assumed they’d never be seen. He delivered the website, billed it and it went live on the Internet. The next day, the studio was ringing his phone off the hook because they had been getting complaints about a variety of four-letter words showing up in people’s consoles.

Part 3 - Solutions.

Improving your console presence is just a matter of trashing your newbie habits and replacing them with one or more of these new habits.

Clean up after yourself
Using trace actions to figure out some part of your code is what trace() is intended for. Once you’re done with that section, put your tools away! Remove or comment the trace statements. Otherwise, your application will eventually flood your console with hundreds of lines of output and you won’t be able to see what you’re actually looking for.

Don’t misplace your trace()
How many times have you been working on a website or application and seen a mysterious message in your output panel like “done”, “load” or “ready now”? These disembodied statements are nearly impossible to track down. Clean up if you leave them scattered around your code. Additionally, these types of messages are absolutely meaningless if you don’t remember what they are referring to. To avoid losing your statements leave breadcrumbs in them. I like to put the name of the class and method where the trace is in the message so I always know exactly what’s tracing, even if it’s months later. Which do you think is more useful: “end” or “[ManagerClass.playIntroduction] end”? You can even use this format in timeline-based code, like this “[backgroundMc.frame32] waiting for intro to end.”

Omit trace actions
Are you working in the Flash IDE? Just take this one easy step before delivering to your client to save yourself from most of these issues. Go to the menu File > Publish Settings… click the Flash tab, under Options: check Omit Trace Actions. Publish and you’re done. All trace() statements will be surgically removed by the compiler.

Use a print line manager
Would you like a more flexible way to manage your output (multiple levels of message severity, ability to filter messages at runtime without recompiling?) I have written a brief post about creating and using a filter-based print line manager at Actionscript.org. You can read the post by clicking here.


Comments

Leave a Reply