←back to thread

376 points turrini | 4 comments | | HN request time: 0.637s | source
Show context
rkharsan64 ◴[] No.42146864[source]
On a general note, I would recommend any new (and experienced!) programmers to master the debugging tools of their ecosystem. I've seen countless experienced developers use printf-based debugging and waste hourse debugging something which could've been easily figured out by setting a breakpoint and stepping through your code. This is also a good way to understand code you're unfamiliar with.

This is one area where I believe a GUI tool is so much better: I can hover over variable names to view their values, expand and collapse parts of a nested structure, edit values easily, and follow execution in the same environment I write my code in.

Sure, it doesn't help much for some scenarios (one I've heard people mention is multithreaded code, where logs are better?), but for most people it's not that far from a superpower.

replies(13): >>42147055 #>>42147066 #>>42147101 #>>42147176 #>>42147333 #>>42147405 #>>42147537 #>>42147789 #>>42147794 #>>42148121 #>>42148413 #>>42149115 #>>42152454 #
mpweiher ◴[] No.42147101[source]
Interesting.

My experience is the opposite: I see developers waste hours stepping through their code a line at a time when a few judiciously placed logs (printfs() are fine, but we can do better) would have told them exactly what they needed in a jiffy.

If you have a fairly shallow bug, that is a single point in your code that always behaves incorrectly, then I find debuggers reasonably effective.

But most of the bugs that I see aren't that shallow, with code misbehaving when the context is just so and perfectly fine otherwise. In those cases, I need to see lots of different invocations and their context. The debugger is like trying to drink the information ocean I need through a straw. A mostly plugged straw.

I wonder what makes our experiences so different? Do you unit test a lot? Particularly with TDD? I am guessing that this practice means I just don't get to see a lot of the bugs that a debugger would help me with.

(And it doesn't mean I never fire up the debugger. But it is fairly rare).

replies(22): >>42147211 #>>42147237 #>>42147245 #>>42147283 #>>42147315 #>>42147373 #>>42147478 #>>42147783 #>>42147884 #>>42147930 #>>42148469 #>>42148634 #>>42148838 #>>42148842 #>>42148881 #>>42148922 #>>42149104 #>>42149226 #>>42151135 #>>42155917 #>>42156264 #>>42179165 #
1. miningape ◴[] No.42147315[source]
Another thing to consider and is important to me - logging objects and state isn't always so simple. It can often be easier for me to open the debugger to look at the state of an object which cannot easily be printed.
replies(1): >>42147419 #
2. mark_undoio ◴[] No.42147419[source]
Out of interest - what sort of objects are hard to print in this way but easy to view in a debugger?
replies(2): >>42147525 #>>42148155 #
3. miningape ◴[] No.42147525[source]
In my case it's basically everything since I work in java, jackson's object mapper can easily get stuck or deserialise something incorrectly if the class hasn't been annotated correctly. So it's simpler for me to pull up the debugger and I can see the "actual" data thats making up my object, it also lets me run "queries" against anything of interest (i.e. computed fields).

The default toString method I've found to be useless almost every time I wanted to inspect an object in our codebase since it just prints the type + "id" for the object

4. antonyt ◴[] No.42148155[source]
An object with many fields (in a language with no conveniences for it). An object tree with multiple levels of nesting. A list or dictionary of such objects.

In general, print-based debugging requires a greater degree of specificity. If you know exactly what you're looking for it's great.

If you are performing a more exploratory sort of debugging, a decent graphical debugger will save you a ton of time.