Live data from Hacker News

You say “cave dweller debugging”, I say debug logging

sicpers.info

1–10 of 139 posts

Re: You say “cave dweller debugging”, I say debug logging

#2
No doubt there is a place (or indeed a need) for debug (or trace) logging in environments where you can’t simply pause execution.

However, in development environments you would be foolish not to use the (vastly superior) tooling available.

I think many developers shy away from debuggers simply because they haven't taken the time to understand how to use them effectively, whereas everyone knows how to write a log statement. In previous roles I have given guidance on usage to fellow team members. It makes a vast difference on the resolution time of reported issues.

Re: You say “cave dweller debugging”, I say debug logging

#3
I liked this idea in principle but in practice I found there's just too many debugPrint() lines cluttering the code, and too much overwhelming console spam, so it's not worth it to keep around debug logging (or taking the time to decide what is worthwhile to keep).

When I fix a problem gnarly enough to require lots of logging everywhere, once I've tidied up I write a detailed comment or other documentation, and/or use unit tests to make sure the problem stays solved. The logging code doesn't get committed, which also helps keep the fixed code clear in the diff.

For the kinds of programs I usually write, I've settled on only using printing/logging for major events and for things that aren't errors but might require developer attention.

Re: You say “cave dweller debugging”, I say debug logging

#4

No doubt there is a place (or indeed a need) for debug (or trace) logging in environments where you can’t simply pause execution. However, in development environments you would be foolish not to use the (vastly superior) tooling available. I think many developers shy away from debuggers simply because they haven't taken the time to understand how to use them effectively, whereas everyone knows how to write a log stat…

Debuggers are great (even when I have to resort to running GDB over SSH with no GUI help) but sometimes you have to debug compiler-optimized code, or asynchronous or long-term problems, and then logging can be a quick and effective alternative.

Re: You say “cave dweller debugging”, I say debug logging

#5
post #3

I liked this idea in principle but in practice I found there's just too many debugPrint() lines cluttering the code, and too much overwhelming console spam, so it's not worth it to keep around debug logging (or taking the time to decide what is worthwhile to keep). When I fix a problem gnarly enough to require lots of logging everywhere, once I've tidied up I write a detailed comment or other documentation, and/or us…

You can often instrument code at build time to facilitate tracing, keeping your code free from much of the logging statements while still providing logs on function calls, arguments and return values. Obviously this (usually) isn't statement-level logging, but its often enough to diagnose issues.

Re: You say “cave dweller debugging”, I say debug logging

#6
post #3

I liked this idea in principle but in practice I found there's just too many debugPrint() lines cluttering the code, and too much overwhelming console spam, so it's not worth it to keep around debug logging (or taking the time to decide what is worthwhile to keep). When I fix a problem gnarly enough to require lots of logging everywhere, once I've tidied up I write a detailed comment or other documentation, and/or us…

> in practice I found there's just too many debugPrint() lines cluttering the code

On this particular aspect - I find that log lines can do double-duty as code comments. When I see some comment that explains the what-and-why of a section of code - "// We also need to check the Foo state for consistency before committing Bar" - I might actually change it to a log line like - "Verifying state of Foo ${foo.id} before committing Bar ${bar.id}".

Re: You say “cave dweller debugging”, I say debug logging

#7
I'm having the same issues...

Although I'm not a full time developer, I do some small coding and I'm also sort of responsible for the dev team. I rarely use a debugger. I do most of debugging through logging. There are 2 advantages that I see:

   - it forces me to add the logs where they are needed to understand the flow of the application
   - it forces me to make those logs actually usable, readable and understandable
Developer's first response on a bug report is - give me logs. But I don't have them, because they were not coded. Or they are unusable because they are not logging the actual problem. Developer then insists the problem is fine because he can't replicate it in his debug environment instead of figuring out the issue from the logs. Making logs during development also forces developers to make a conscious effort of finding a balance of what and when to log something, create proper debug levels not to overwhelm the logs, while still providing some useful information...

Re: You say “cave dweller debugging”, I say debug logging

#8
post #4

No doubt there is a place (or indeed a need) for debug (or trace) logging in environments where you can’t simply pause execution. However, in development environments you would be foolish not to use the (vastly superior) tooling available. I think many developers shy away from debuggers simply because they haven't taken the time to understand how to use them effectively, whereas everyone knows how to write a log stat…

Debuggers are great (even when I have to resort to running GDB over SSH with no GUI help) but sometimes you have to debug compiler-optimized code, or asynchronous or long-term problems, and then logging can be a quick and effective alternative.

Sometimes you have to debug distributed solutions, and like you say you may have to do it in an optimized environment. You may also have to do it in an environment for which you have no other access than console output. I've been working in these kinds of environments for so long I've practically forgotten how to use a debugger!

Re: You say “cave dweller debugging”, I say debug logging

#9

No doubt there is a place (or indeed a need) for debug (or trace) logging in environments where you can’t simply pause execution. However, in development environments you would be foolish not to use the (vastly superior) tooling available. I think many developers shy away from debuggers simply because they haven't taken the time to understand how to use them effectively, whereas everyone knows how to write a log stat…

> However, in development environments you would be foolish not to use the (vastly superior) tooling available.

The debugger being vastly superior is highly dependant on what environment you are running in.

Post reply on HN