Hacker News Reader

Comment by gbersac | Hacker News Reader

I just use printf and other stuff to dump critical variable. I also use unit test a lot.

Ah yes, the good ol' printf-debug-polluting-codebase method. What's fun after that, is when programmers all start competing to have their printf's be more visible in the sea of prints ... I find this method primitive at best. How do you manage it?

You remove the printfs when you have fixed the problem.

It's so tempting to do this. Don't. Problems may occur again in the same area. Leave your logging statements around; configure your logging setup to skip them when you don't want them.

You're saying to delete commented-out code once the new code works. Put your code in version control instead. Logging is to once-off printfs as version control is to commented-out code.

Not so sure. Once I get to the stage where I have to stick printfs in the problem tends to be so localized and specific that once fixed I will never need to look at that area of code in that way again.

I do this far more than I should. The code ends up a mess after enough debugging like that.

I think he meant to add print statements locally. You remove them before committing the code.

I find this method primitive at best. How do you manage it?

Don’t be primitive about it. :-)

The serious answer is: use a good logging framework. In particular, I’d suggest something that can log at selective levels of information for different parts of your system.

If your project’s culture is to instrument your code like this routinely, it can be a very useful asset, and it’s no more disruptive in practice than say adding comments or writing tests. In each case, with experience you get better at judging where to focus your efforts and how much detail is worth including by default, and if that turns out not to be enough you can always add more while you’re working in that area.

With modern tools for recording and analysing logs, there is relatively little useful information that you can easily find using a debugger but can’t easily find from good log output. On the other hand, logging has some big advantages: you can capture how your system changes over time, you can record and review concurrent behaviour cleanly, you can capture information from different parts of distributed systems that might be written in different programming languages or running on different devices.

In my case, aggressively reject any printf statements in code review. Get that shit out of my repo.

Without trace statements, how do you diagnose issues that don't occur locally and only appear in the production environment.

That would be the difference between printing and logging

Traces are the kind of thing that should be automated anyway... You shouldn't have to write explicit trace statements in your source code, instead your language or framework should have an automated way of inserting these statements at function boundaries. Or even better, attach a debugger and reproduce the issue yourself on the prod server.

Just plain "debug log statements" I have yet to hear a good use case for. Every time people have put them in, it's because some bug called for their inclusion, then the bug got fixed, then the statements got left around after the bug was fixed. Or the bug didn't get fixed and it's a matter of "why don't you fix the bug?"

There's rare cases where there's an ongoing issue with a known bug that you don't know the fix for yet, so you drop debug statements in production code hoping to catch it. But this is supposed to be a rare, rare case.

printf = breakpoint expression evaluation (but without the flexibility)

You're using a primitive debugger, you just don't know it.

It does have the advantage of both immediacy and continuation.

You can dump statements through a function and see it's progression when run without having to interact with it.

Throw in something like FirePHP (which allows dumping pretty much anything out as a viewable/collapsible trace, other languages have similiar) and the use case for a lot of using a full blown debugger is removed (it's still incredibly powerful when needed).

So I use both.

Codebug + Xdebug, setting a breakpoint and getting a full REPL at that execution point is far more useful to me when I'm in PHP land :)

I tend to do that mostly for concurrent programs, as I want to see what happens without blocking the entire system like a debugger would.

For medium/large programs I'll often prefer a debugger because I can easily and quickly try to diagnose the problem without having to wait for a new build to complete with the added traces.

Reply on news.ycombinator.com