I'm a self taught C# programmer and up to now I haven't really been making use of Debug and Trace and feel as though I should use them.  I've been leaning more on TDD to understand and get feedback from my code.The .Net Framework Developers Guide declines to specify general guidelines for strategic placement of trace statements because applications that use tracinig vary widely...;What are your experiences of using Debug/Trace? Does using them too much create code maintenance issues? How much output is too much? How much is too little?  What sorts of things do you tend to record?
How Do You Effectively Use Trace And Debug
language agnostic
From a developer's point of view having a large amount of tracing information is an absolute godsend when you get a bug report from a customer as often it allows you to reproduce and diagnose the cause of a bug quickly from a log file: not all bugs raise exceptions, and this goes doubly so for the really nasty ones.When a bug report comes in I would say the more verbose the logging the better. Also when you are executing your code, to be able to watch what it is doing in real time in debug view is very useful indeed, especially for multithreaded code. I guess that this needs to be qualified by saying you want to minimise repetition to improve readability; but in general when a bug arrives on your desk you are generally not asking for less information.There however some very good reasons for not using tracing:It can lead to horrific, ugly boilerplate code bloat that can prevent refactoring. Putting an enter function exit function on nearly every method is a maintenance nightmare and looks wrong. In C# you can use Post Sharp which solves this problem by injecting IL into your code so you never see those calls, but in general I guess there is no way around this.It slows you code down. This might not be too much of a problem: if the bottleneck in execution is accessing the database, then verbose logging won't be an issue. However, if it is the computations themselves that are the bottleneck then verbose logging is likely to make your code too slow to be usable.The data might contain sensitive information that you cannot log: there are ways around this such as encrypting the log file on the fly, but this then comes at a performance overhead, and only you know if that is acceptable for your application or not.Huge amounts of trace data can become unwieldy. For example the Microsoft unit testing framework for Visual Studio will display the entire trace / debug log after a unit test fails: if your code is small and atomic I'm sure that works really well. If you have code that does not lend itself to testing easily and you end up creating a few MBs of trace / debug data to run a single test then the IDE will hang for a minute or two while it tries to display that data.