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?

  • 1
    At my organization, any time a developer leaves import pdb; pdb.set_trace() where it can find its way into a release, they owe QA $5. – SingleNegationElimination May 22 '11 at 2:13
  • I'm aiming more at Debug/Trace.WriteLine("Stuff etc.") calls than Debbuger.Break() for which $5 sounds reasonable. – Grokodile May 22 '11 at 2:40

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:

  1. 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.
  2. 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.
  3. 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.
  4. 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.
  • 1
    A possible workaround is to keep trace information in memory in unexpanded form, and only in case of an exception convert it to humanly readable form. When the information gets old just drop the objects. This is much cheaper than writing gigantic log files. – user1249 May 22 '11 at 8:04
  • 1
    The issue with that is that not all bugs raise exceptions. But yes, I think the solution is to make logging more configurable and granular. – user23157 May 22 '11 at 9:04
  • 1
    If the bug doesn't trigger an exception then enable full logging so you have a logfile to work with. – user1249 May 22 '11 at 9:13

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.