undefined | Better HN

0 pointsscarface746y ago0 comments

So I don’t often use a debugger because a lot of the scenarios like that where I might have been reduced greatly, again, by better tools, better testing

I would actually say the opposite. If you’re littering your code with print statements and #if DEBUG equivalents (instead of using a debugger) and grepping log files (instead of using a structured logging library) you’re not using the newest tools available and you’re “debugging” in a way that I gave up in the mid 90s writing C and FORTRAN for DEC VAX and Stratus VOS mainframes.

There is nothing “modern” about littering your code with print statements. I thought being forced to do that in the 90s was already taking a step back from the various DOS based IDEs I had used by then.

0 comments

jchw6y ago

The thing is, your imagination of what I’m doing (littering code with printf statements) and the actual reality of what I'm doing (solving AT LEAST 95% of my problems using extensive automated tests, strong linting, strict typechecking, and modern programming practices) is leagues apart. When I say I break out the debugger around every few months, I am not exaggerating. I may insert a printf or two once every other week. This is not the common case, it’s just significantly more common for me than attaching a debugger, because it’s quick and easy.

The practice I adhere to is to break code up into small modular bits then unit test the living hell out of those bits, then integration test larger combinations. Maintaining test code takes time, but I take it very seriously. I can’t share any of my actual work at Google but I can share my open source work; a project that I wrote this way is Restruct and it normally has around 98% line coverage. If someone finds a bug I add a new test. I have never used a debugger on Restruct or projects built on Restruct.

So then, what do I do all day? Console.log and printf everything? No, honestly no. I spend little of the day debugging because unit tests tell me nearly exactly what codepaths I broke, printing out helpful diffs of the expected behavior versus the actual behavior. This almost always gives way to the problem, even when I’m working on a brand new piece of code with tests I just wrote (sometimes before the code, even.)

So I would say printf is my goto debugging tool, but if I want to be accurate, it’s probably really automated testing. Automated testing used in this fashion basically acts as small little debug routines. We don’t call tests debugging tools though, because that would undermine their usefulness; they do so much more. Which is why I don’t sweat it when I have just as much or more test code than actual code; unlike other code, it often pays for itself if you do a good job.

And besides, if unit tests explain a bug to you before you actually run into it, did you really do any debugging or did you bypass it entirely?