I am a puts debuggerer
tenderlovemaking.com
I am a puts debuggerer
1–10 of 60 posts
Re: I am a puts debuggerer
#2I'm an everything debuggerer. I use print statements when its convenient (mainly when i want to know what's going on in a longer process), i use interactive debuggers when its convenient (mainly when i want to inspect complex data structures), sometimes i run the interactive debugger and then dump a complext data structure to STDOUT with a print (mainly when i want to reference it later on).
I don't get the people who insist on using only one thing, and claim that their thing is the best. There's lots of tools and all of them have different optimal use cases.
Re: I am a puts debuggerer
#3I've always found people skilled with debuggers look like they have super powers. Symbolic debuggers really are tricky, and these are some good tips.
Re: I am a puts debuggerer
#4Sometimes, just dumping stuff out to the console is the best.
Especially in multi-threaded code, it can be the only way - hitting a breakpoint and stepping through causes other threads to time out in unnatural ways, and you're hosed tracking down things that wouldn't actually happen. It's not uncommon that I've run into issues where attaching a debugger or a profiler gets its hooks into something in the depths of whatever COM library I'm using that breaks it anyway (I love RedGate's performance profiler, but I can't use it for some things on Windows 10, because of some security something or other, while it works on 7 & 8...)
Log4net is, without a doubt, my favorite dependency. ColoredConsoleAppender FTW. Even better, if I take the slightest care with my log levels in code, I can tune the log output up and down just by tweaking the config. So I can leave full diagnostics in a release, tune things down to hide the verbosity, with minimal performance hit, and dial it back up to debug levels if I encounter an issue in production.
Re: I am a puts debuggerer
#5I've used gdb a few times, but I've always defaulted to print statements. It just... it just works, okay?
I get that there are definitely times when a legitimate debugger would come in handy, but I've never gone wrong with "puts debugging."
Re: I am a puts debuggerer
#6Re: I only want to see the stack trace in certain cases
(C++) One of my favorite middle grounds between console debugging and loading up the debugger is to output the actual stack walkback as a string of hex addresses in production code (on a conditional log level). This is relatively very cheap and avoids the entire cost of loading up the machinery to resolve the addresses to symbols in the critical path. It is assumed that you know what binary is running where and that you associate the stack walkback with the unique binary and thus can resolve the symbols out of band at a later date. (.. or have some handy automation that is notified and does it for you out-of-band and puts the results back into the central logging facility :))
At Bloomberg we do this using part of our infrastructure libraries and have wrapped up the logging-the-stack-as-hex part into a simple drop-in call: https://bloomberg.github.io/bde/group__balst__stacktraceutil...
All of the conditional logging machinery is pretty important as well, as it lets you maintain all of your detailed logging statements with the flexibility to configure however you wish at runtime in a production build while debugging. There's many different solutions for this in the C++ world, but ours is here: https://bloomberg.github.io/bde/group__ball__log.html The rest of the components are all in that package: https://bloomberg.github.io/bde/group__ball.html
Re: I am a puts debuggerer
#7I've noticed that the more stateful my code, the more use I get from a debugger. Being able to poke and prod and see the various values in memory can be extremely helpful when I'm writing in an OO language, that just spitting to console doesn't really do (because I don't know up front what I'm going to care about; what influences what, what values are in the stack, in a containing object, etc).
Conversely, the less state I have (and, typically, the more functional my code), the less useful debugging is. It becomes easier to see my bugs up front (as they have more to do with explicit logic, that is expressed directly in my code), and to trace through in my head what must be going on, and all I need to do is check to confirm my understanding, and that my fix addresses it correctly, which can often be done more easily by just running the code twice (with a puts/print statement), than attaching a debugger twice.
Re: I am a puts debuggerer
#8I'm an everything debuggerer. I use print statements when its convenient (mainly when i want to know what's going on in a longer process), i use interactive debuggers when its convenient (mainly when i want to inspect complex data structures), sometimes i run the interactive debugger and then dump a complext data structure to STDOUT with a print (mainly when i want to reference it later on). I don't get the people wh…
Upvoted and agreed. It really depends on the complexity of the problem at hand what tool is most suitable.
Re: I am a puts debuggerer
#9It's great find people like you and me :)
I'm a pprint, fmt.Println, panic, console.debug, log.Print debugger !!
Re: I am a puts debuggerer
#10I don't even understand the 'have to learn a debugger' statement. Is he referring to things like pry? I rather enjoy the debugger in Rubymine, and part of the reason for this is that it more or less works like every other debugger I have ever used (eclipse, vs, chrome debugger, etc.)
There is not much to learn if you have used any debugger in the past.