Don’t look down on print debugging
blog.startifact.com
Don’t look down on print debugging
1–10 of 164 posts
Re: Don’t look down on print debugging
#2To me there are three requirements for me to be comfortable with a team culture of print-debugging.
1. If a breakpoint debugger exists for the stack, it should still be convenient and configured, and the programmer should have some experience using it. It's a skill/capability that needs to be in reserve.
2. The project has automatic protections against leftover statements being inadvertently merged into a major branch.
3. The dev environment allows loading in new code modules without restarting the whole application. Without that, someone can easily get stuck in rather long test iterations, especially if #1 is not satisfied and "it's too much work" to use another approach.
Re: Don’t look down on print debugging
#3If you feel shame because of random opinions and articles on the internet, I’d address that before worrying about “print” vs. a real debugger.
I pretty much only use print debugging. I know how to use a real debugger but adding print/console.log etc. keeps me from breaking context and flow.
Re: Don’t look down on print debugging
#4The shortcoming is print cannot always inspect pointers/objects. Once the debugger hits the breakpoint the entire context can be inspected.
Re: Don’t look down on print debugging
#5To me there are three requirements for me to be comfortable with a team culture of print-debugging. 1. If a breakpoint debugger exists for the stack, it should still be convenient and configured, and the programmer should have some experience using it. It's a skill/capability that needs to be in reserve. 2. The project has automatic protections against leftover statements being inadvertently merged into a major branc…
Why would debugging be a team culture thing? It's very individual in practice.
Re: Don’t look down on print debugging
#6If anyone is making you feel ashamed for using one of the most fundamental, bread and butter debugging techniques, that's a red flag about that person. Not you. If there are better tools available, fine, use 'em. But there is absolutely nothing wrong with tossing out a console log to see what's going on.
Re: Don’t look down on print debugging
#7If you feel shame because of random opinions and articles on the internet, I’d address that before worrying about “print” vs. a real debugger. I pretty much only use print debugging. I know how to use a real debugger but adding print/console.log etc. keeps me from breaking context and flow.
I only use print debugging when working on the web, and your mention of console.log makes me think maybe you're in the same boat.
It's an absolutely damning indictment of the developer experience for the web that this is the case. Why aren't our IDEs and browsers beautifully integrated like every other development environment I use integrates the runtime and the IDE?
Why hasn't some startup, somewhere, fixed this and the rest of the web dev hellscape? I don't know.
Re: Don’t look down on print debugging
#8The shortcoming is print cannot always inspect pointers/objects. Once the debugger hits the breakpoint the entire context can be inspected.
Print debugging has no problem inspecting pointers, you just gotta decide ahead of time which pointers you want to inspect and which members of the structure it's pointing to are relevant.
Re: Don’t look down on print debugging
#9Some of the trickiest bugs to hung down are those involving concurrency and non-deterministic timing. In these cases, stepping through a debugger is not at all what you want, since you may actually change the timing just by trying to observe.
To see the nature of the race condition, just put some print statements in some strategic locations and then see the interleaving, out of order, duplicate invocations etc that are causing the trouble. It's hard to see this type of stuff with a debugger.
Re: Don’t look down on print debugging
#10Debugger vs print? No, the most smug response to that debate I ever heard was "Neither, I use unit tests".