How to keep your own debug lines without checking them in?

Question

When working on some code, I add extra debug logging of some kind to make it easier for me to trace the state and values that I care about for this particular fix.

But if I would check this in into the source code repository, my colleagues would get angry on me for polluting the Log output and polluting the code.

So how do I locally keep these lines of code that are important to me, without checking them in?

Clarification: Many answers related to the log output, and that you with log levels can filter that out. And I agree with that.

But. I also mentioned the problem of polluting the actual code. If someone puts a log statement between every other line of code, to print the value of all variables all the time. It really makes the code hard to read. So I would really like to avoid that as well. Basically by not checking in the logging code at all. So the question is: how to keep your own special purpose log lines. So you can use them for your debug builds, without cluttering up the checked in code.

Answer 1

What source control system are you using? Git allows you to keep local branches. If worse comes to worst, you could just create your own 'Andreas' branch in the repository, though branch management could become pretty painful.

Answer 2

But if I would check this in into the source code repository, my colleagues would get angry on me for polluting the Log output and polluting the code.

I'm hoping that your Log framework has a concept of log levels, so that your debugging could easily be turned off. Personally I can't see why people would get angry at more debug logging - because they can just turn it off!

Answer 3

Why not wrap them in preprocessor directives (assuming the construct exists in the language of your choice)?

#if DEBUG
    logger.debug("stuff I care about");
#endif

Also, you can use a log level like trace, or debug, which should not be turned on in production.

if(logger.isTraceEnabled()) {
    logger.log("My expensive logging operation");
}

This way, if something in that area does crop up one day, you can turn logging at that level back on and actually get some (hopefully) helpful feedback.

---

Note that both of these solutions would still allow the logging statements to be checked in, but I don't see a good reason not to have them checked in. I am providing solutions to keep them out of production logs.

Answer 4

Similar to

#if DEBUG #endif....

But that will still mean that anyone running with the 'Debug' configuration will hit those lines.

If you really want them skipped then use a log level that no one else uses, or....

Create a different run configuration called MYDEBUGCONFIG and then put your debug code in between blocks like this:

#if MYDEBUGCONFIG 
...your debugging code
#endif;

Answer 5

If this was really an ongoing problem, I think I'd assume that the central repository is the master version, and I'd end up using patch files to contain the differences between the official version (the last one that I worked on) and my version with the debugging code. Then, when I needed to reinstate my debug, I'd check out the official version, apply my patch (with the patch command), fix the problem, and before check in, remove the patch with patch -R (for a reversed patch).

However, there should be no need for this. You should be able to agree on a methodology that preserves the information in the official code line, with mechanisms to control the amount of debugging that is produced. And it should be possible regardless of whether your language has conditional compilation in the sense that C or C++ does, with the C pre-processor.

Answer 6

IMHO, you should avoid the #if solution. That is the C/C++ way of doing conditional debugging routines. Instead attribute all of logging/debugging functions with the ConditionalAttribute. The constructor of the attribute takes in a string. This method will only be called if the particular pre-processor definition of the same name as the attribute string is defined. This has the exact same runtime implications as the #if/#endif solution but it looks a heck of a lot better in code.

Answer 7

If you really are doing something like:

puts a log statement between every other line of code, to print the value of all variables all the time. It really makes the code hard to read.

that's the problem. Consider using a test framework, instead, and write the debug code there.

On the other hand, if you are writing just a few debug lines, then you can manage to avoid those by hands (e.g. removing the relevant lines with the editor before the commit and undoing the change after it's done) - but of course it have to be very infrequent!

Answer 8

I know i'm going to get negative votes for this...
But if I were you, i'd just build my own tool.

It'll take you a weekend, yes, but you'll keep your coding style, and your repository clean, and everyone will be happy.

Not sure what source control you use. With mine, you can easily get a list of the things that are "pending to be checked in". And you can trigger a commit, all through an API.

If I had that same need, i'd make a program to commit, instead of using the built-in command in the Source Control GUI. Your program would go through the list of pending things, take all the files you added/changed, make a copy of them, remove all log lines, commit, and then replace them back with your version.

Depending on what your log lines look like, you may have to add a special comment at the end of them for your program to recognize them.

Again, shouldn't take too much work, and it's not much of a pain to use later.
I don't expect you'll find something that does this for you already done (and for your source control), it's pretty specific, I think.

Answer 9

If the only objetive of the debugging code you are having problems with is to trace the values of some varibles I think that what you really need is a debugger. With a debugger you can watch the state of any variable in any moment.

If you cannot use a debugger, then you can add some code to print the values in some debug output. But this code should be only a few lines whose objective has to be to make easier the fix you are doing. Once it's commited to trunk it's fixed and then you shouldn't need more those debug lines, so you must delete them. Not delete all the debug code, good debug code is very useful, delete only your "personal" tracing debug code.

If the fix is so long that you want to save your progress commiting to the repository, then what you need is a branch, in this branch you can add so much debugging code as you want, but anyway you should remove it when merging in trunk.

Answer 10

This next suggestion is madness do not do it but you could...

Surround your personal logging code with comments such as

// ##LOG-START##
logger.print("OOh A log statment");
// ##END-LOG##

And before you commit your code run a shell script that strips out your logs.

I really wouldn't reccomend this as it's a rubbish idea, but that never stops anyone.

Alternative you could also not add a comment at the end of every log line and have a script remove them...

logger.print("My Innane log message"); //##LOG

Personally I think that using a proper logging framework with a debug logging level etc should be good enough. And remove any superfluous logs before you submit your code.