4 ms·
I just use printf and other stuff to dump critical variable. I also use unit test a lot.
by gbersac 11y ago
I just use printf and other stuff to dump critical variable.
I also use unit test a lot.
- kelvin0 11y agoAh 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?
- weavie 11y agoYou remove the printfs when you have fixed the problem.
- thaumasiotes 11y agoIt'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.
- weavie 11y agoNot 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.
- collyw 11y agoI do this far more than I should. The code ends up a mess after enough debugging like that.
- casta 11y agoI think he meant to add print statements locally. You remove them before committing the code.
- Chris_Newton 11y agoI 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.
- ninkendo 11y agoIn my case, aggressively reject any printf statements in code review. Get that shit out of my repo.
- lberger 11y agoWithout trace statements, how do you diagnose issues that don't occur locally and only appear in the production environment.
- ninkendo 11y agoTraces 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.
- robertfw 11y agoThat would be the difference between printing and logging
- jeremiep 11y agoI 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.
- barrkel 11y agoprintf = breakpoint expression evaluation (but without the flexibility) You're using a primitive debugger, you just don't know it.
- noir_lord 11y agoIt 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.
- girvo 11y agoCodebug + 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 :)