What's good code without good Trace!
Senior Flash Developer for US based company. I've been coding in Flash for about 7 years. I've been doing AS3 development for the passed 3 years. I have developed more than 50+ complete web and desktop applications done exclusively in Flash. I specialize in advanced coding for the layman. I've developed my own MVC framework and coding library suite for our company's internal development.View all articles by Thom Duppstadt
As a rule, I leave enough trace to know what the program is doing without having to look at the stage... but removing those needed for a detailed troubleshooting session that has since been resolved. Now formatting your trace.. I use...
trace (" * <ClassName.methodName> information to be traced");
...For submethod data tracing. I simply format it like this.
trace (" * -- Submethod data trace");
...then for alert traces, for example this method did a check and came up possitive for a null object. I use this....
trace ("! <ClassName.methodName> object x returned null");
What's important to note here are the spaces in the beginning of the trace. I add the ' * ' to my trace because doing this will distinguish my trace from a Flash trace and or external class issued trace. Including the class name and the method name in the trace obviously keeps you informed from where the trace is coming from. This might seem tedious at first but it REALLY makes a difference. The alert trace uses '! '. With the initial space removed adding in the '!' again makes this call stand out. I also include empty line traces trace (); to help distinguish key events in program... like going into a new section or whatever. Or a line of underscores to indicate major section divisions.
This seems like a simple thing and to some may even think this seems trivial, but I have enough experience to tell you that if you organize your traces, debugging is much faster and it will keep you up to speed with what your program is doing (before it's too late) HA.