Software Engineering Stack Exchange is a question and answer site for professionals, academics, and students working within the systems development life cycle. It only takes a minute to sign up.
Sign up to join this community
I, for one, only add debug code (such as print statements) when I'm trying to locate a bug. And once I've found it, I remove the debug code (and add a test case which specifically tests for that bug). I feel that it's cluttering the real code and therefore has no place there unless I'm debugging.
How do you do it? Do you leave the debug code in place, or remove it when obsolete (which may be difficult to judge when that is)?
Debug print statements should be taken out; however, if you're needing to add them to debug a production problem then it may be worth considering if you have enough information being put into your logging framework. Information about parameters, error conditions and so on may well be useful later on when the next bug appears. Using a good logging framework that can be have debug or tracing log messages turned on dynamically can be very useful in the wild.
ChrisF and Alaric both have valid points; +1 for them. I can identify at least 5 different types of debug code that I use.
Using logs to dump system state at a specific point in time.
void function(...)
{
...dump everything i know about.
}
Using logs for execution check points.
void function(...)
{
...got here 1
...got here 2
}
Code that actually forces a certain condition to be true, but breaks normal behavior. Example:
Verification logging - I would classify this as a verbose logging that can be used to validate the software's correctness that should not be included in production, like validating the individual steps of an algorithm for example.
Operation logging - refer to Alaric's post. That is pretty much what I mean by "operation logging".
1, 2 and 3 should be taking out completely. Something like 4 I would probably conditionally compile out of the code. For 5, Alaric had a great point about being able to dynamically turn the logs off. That may address ChrisF's point in his second bullet for most cases.
1) … with 1. … (so that the Markdown formatting picks it up as a lists) and indenting the example code by 8 spaces (again, so that Markdown picks it up as an example code within a list).
Jan 3, 2011 at 10:09
Code added specifically for debugging should be removed from production software.
Whether this is complete removal or being put into conditional compilation sections (as in C/C++/C#) is up to you and your coding standard.
There are a number of reasons for this:
If there are times when you might need the debug output then leaving it in and compiled but putting it's execution in conditional statements controlled by configuration would be an acceptable compromise. For most of the time the code isn't executed but can be at the flip of a switch. Obviously point 1 about potential security implications of this should be considered.
It depends on what the code is doing. Some code that is used for debugging can be left as it is, and some should be removed.
Code that verifies the sanity of the parameters in a method isn't always useful once the code is working properly, but it's often kept to make sure that the code is continuing to work properly.
Sometimes you write code differently to make it easier to debug the code, for example calculating a value and putting it into a local variable, and then use the variable in next line, which makes it easy to check the result of the calculation when single stepping through the code. You could rewrite the code to use the calculated value directly, but the cost of using the local variable is so small (if any at all) that there is little reason to rewrite the code. Also, there is a point in leaving the code unchanged once you have tested it, there is always a small risk that you introduce a bug when changing it.
Code that you add just to track down a specific bug can often be removed after you have found the bug.
Once upon a time I used to use a lot of debugging code. I was almost entirely targeting Windows, so there was lots of this debug string output function that I don't remember how to spell any more, so I could capture the trace with a particular program.
Some debug code stayed in place, particular stuff that was intended to give the nesting of calls. However, even though the debug string thing mostly wouldn't be visible on a production system, it was still all done under conditional compilation.
The reality is, though, that all that debug code was a lot of effort for something that is ideally handled a different way - using, of course, a debugger. At the time, I wasn't that impressed with the Borland C++ debugger. The tools were there, but they too often gave misleading results, and using the non-IDE debugger (often necessary) meant memorizing shortcut keys, which meant a distraction from the job at hand.
The only debugging experience I've found that's worse is command-line GDB.
Being an expert with the tools you use every day is, of course, important - but debugging really shouldn't be something you do every day. If you use the debugger so often you're OK with learning dozens of commands and/or keyboard shortcuts, that seems a bit red flag-ish to me.
By the time I was working in Visual Studio 7, though, it was clear that debugging could be very practical and effective. If you can do your debugging in Visual Studio (express editions included), debugging is a breeze. No doubt if you can find the right GUI/IDE front end, GDB is easy and effective too, though I've not yet done that search.
There's also something to be said for unit testing, with coverage analysis using gcov. The more confident that you are in the behaviour of your libraries, the less deep your debugging needs to be - and the less often you need the debugger in the first place. And writing unit tests is quite reasonably something you should be doing most days.
Unexpectedly important tool = cmake, a build tool that allows me to easily switch between building for GCC and for VC++, among other things. So I can do my unit testing and gcov-based coverage using GCC, but easily switch to VC++ to use the debugger.
My take on it: Debug code used to kill a bug within the code in question I generally remove entirely. Debug code used to kill a bug resulting from outside forces I generally simply comment out.
If the bug is from the unit testing or from internal, the debug code could be removed altogether. But if the bug is from the production, the debug code better be there inside the compile tags. Putting it inside compile tags will help the other developers to understand that this code is only for debug purpose.
Use TDD, so your test code always has a place where its even maintained.
