I Trace, Therefore I Know Where I Am
http://www.actionscript.org/resources/articles/1099/1/I-Trace-Therefore-I-Know-Where-I-Am/Page1.html
Thom Duppstadt
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. By Thom Duppstadt
Published on June 28, 2011
Logical and consistent tracing is essential, particularly when it comes to large projects. I've heard some purists say that your final output should not contain any traces. Agreed; however, you can simply do this with the 'Omit Trace' checkbox in the Flash publishing options. Yes, this should be done for a cleaner output and possible boost in performance but as far as removing all of them from your source code? HELL NO! Trace keeps you sane, it let's you know it's doing or NOT doing what it's suppose to. Just because your program purrs like a kitten doesn't mean you don't have issues. Like events being triggered 100 times unwittingly or objects on the stage that are declaring themselves when you thought you already removed them. Keep your trace! Just organize them and remove what's unnecessary.
What's good code without good Trace!
Logical and consistent tracing is essential, particularly when it comes
to large projects. I've heard some purists say that your final output
should not contain any traces. Agreed; however, you can simply do this
with the 'Omit Trace' checkbox in the Flash publishing options. Yes,
this should be done for a cleaner output and possible boost in
performance but as far as removing all of them from your source code?
HELL NO! Trace keeps you sane, it let's you know it's doing or NOT doing
what it's suppose to. Just because your program purrs like a kitten
doesn't mean you don't have issues. Like events being triggered 100
times unwittingly or objects on the stage that are declaring themselves
when you thought you already removed them. Keep your trace! Just
organize them and remove what's unnecessary.
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...
[as]trace (" * <ClassName.methodName> information to be traced");[/as]
...For submethod data tracing. I simply format it like this.
[as]trace (" * -- Submethod data trace");[/as]
...then for alert traces, for example this method did a check and came up possitive for a null object. I use this....
[as]trace ("! <ClassName.methodName> object x returned null");[/as]
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.
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...
[as]trace (" * <ClassName.methodName> information to be traced");[/as]
...For submethod data tracing. I simply format it like this.
[as]trace (" * -- Submethod data trace");[/as]
...then for alert traces, for example this method did a check and came up possitive for a null object. I use this....
[as]trace ("! <ClassName.methodName> object x returned null");[/as]
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.