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...

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.