Debugging printf is OK – Alex Dixon

I stopped going on Twitter long ago because it tends to stir up anger, as it was designed to do. But every now and then I come back – it can be useful sometimes for continuing graphics research, gamedev news and some people posting cool stuff, like sharing projects they’re working on , so there is something that pulls me out of time.

After checking the other day I saw this debate going around about not using an IDE or debugger, just using ‘notepad’ to write code. I looked at the comments, people arguing about who was right and all the usual toxic vibes, and it reminded me of some earlier occasions of people discussing the same topic.

It seems like the same old debate has been going on for a long time, it’s packaged differently each time, but I really don’t know why people get offended by those things. The main arguments are “if you have to use a debugger you’re an idiot and you can’t understand the code you’re writing” (that’s not an actual quote but along the same lines). Then there’s “If you can’t use a debugger you’re an idiot”. Hatred of the ‘printf’ crew is everywhere.

At the risk of blowing a hornet’s nest, I just wanted to share some thoughts and ideas on this topic in a balanced way, because I don’t think there is necessarily a final solution here. We need to debug the code and there are tools that help us, some are more useful than others in certain situations, but at the end of the day do whatever you have to do to fix the bugs.

Debuggers

I often use a debugger, I launch most C++ work from Visual Studio or Xcode and preferably run a debug build. I know that for some people this is often a terrible UX due to doing debug builds, so a requirement here is fast debug builds. It’s hard to retrofit but having a handy debug build is useful. Once running I can use the debugger break and step if I need to, and if I encounter a crash then there is a nice call stack I look through in more detail.

I have noticed that it is very common for graduate and junior software engineers to have little or no debugging knowledge or experience. This is not something that seems to be taught at university and I have also been told stories of teachers imposing their use of VIM and esoteric debugging strategies on students. For the record I am not a VIM user (another topic that ends up in polarizing debate). I find that using the mouse and 2 finger typing works for me.

The moment you show someone how to use a hardware breakpoint or a watchpoint and immediately find a bug like seeing a light bulb appear over their head, a whole world that has the potential to open before them, or the frustration of wasted time. trying to capture some dodgy logic through layers and layers of object oriented spaghetti.

Some argue about using only ‘notepad’ and no debugger because they can dry run their code on paper and they “don’t write bugs”, but I find it hard to understand how they work within larger team project or codebase. Many bugs and issues I need to fix are not in the code I wrote myself, they are in legacy systems, partner code, or in open source code (and some are hard to track down in the nails bugs! ) lifted in a project. If you believe in the impending AI coding apocalypse then human engineers may just be around to debug and fix issues with AI generated code. So yes, being able to write the perfect code yourself is one thing, but using a debugger to debug the existing code of a large complex project is not something to be ashamed of and maybe we need all the tools we can to help.

With debuggers we get all kinds of other tools, which should also be used when we need them. Addressing the sanitizer can quickly catch memory issues, where in the past we had a 1 in 1000 crash somewhere reading outside of an array’s boundaries, we can do ASan and get it every time without the undetermined nature of the lottery. Same with the undefined behavior sanitizer, now we can catch UB when it’s benign and not just when a noticeable side effect occurs.

I don’t know if these notepad-only coders are also taking all the tools off the table, but if you have something like ASan that’s going to be an issue for you I just don’t know why you don’t use it. I’ve seen a lot of comments that seem to suggest that the debugger is slowing it down, but in this case I’m pretty sure the debugger is speeding you up.

So if you’re reading this and you don’t know about these tools I’d say take a look and see, they might be useful and might save you a lot of time. There are so many things you can do and it’s hard to cover everything here. I learned a lot from working with other people and debugging difficult problems. I think there should be more resources to teach these skills instead of them being given information.

Debugging printf is OK

So for the ‘printf’ haters I will also say that while using a debugger most of the time, I sometimes revert to ‘printf’ debugging. There are some situations where there is no other option – in the past I had to debug the release of builds where we were not able to reproduce the bug in the debug. Even pulling the debug modules for the machine (for debugging information on screen) changed the executable so we couldn’t reproduce the issue. The last thing is to put some print statements using the raw ‘printf’ and remove them and add more as we narrow down the issue and finally get enough information to solve the problem.

I also need to use ‘printf’ when debugging certain types of behavior in an application. In the case of something like touch event tracking for mobile devices, if you try to debug an issue with breakpoints you interrupt the hardware and it makes it difficult to reproduce the same issues. way it appears naturally. So this is where printing the status of touch events, touch events, and seeing the logical flow can identify a problem. There are many more scenarios that benefit from this type of debugging. Just drop the copies and make sure to delete them afterwards so no one knows you’re there, like a ninja.

UI-based debugging tools would be a step further than printf debugging, providing some of the same characteristics but also allowing more flexibility and control, I think that notepad wielders who don’t use a regular debugger should have some custom tools and things to help them. tracking issues. I’m a big fan of embedded debugging and profiling tools within an application. You know things like performance counters that I can just pop up in a UI or changeable values ​​to help refine behaviors or visual appearance. I find that since the explosion of ImGui the level of integrated ad-hoc debugging tools and information has increased rapidly.

But with these types of custom tools, I personally don’t try and reinvent the wheel. I aim to build things that complement the existing tools I get off the shelf. So for example I want to have a quick, at a glance profiler for all my key performance hotspots that I can check if I notice something. But for deeper profiling I would use a CPU or GPU profiler to dig deeper.

Just do what needs to be done

At the end of the day, finding bugs is just something we have to do, anything that helps you find and fix the issue doesn’t bother me as long as we get the job done. On a closing note, I noticed some code in a pull request that someone else accidentally did:

if(some_condition) {
    int x = 0;
}

I found it interesting. I do the same thing except I usually call my variable ‘a’. This is inserting some code where a breakpoint can be set on the ‘int x’ line and then it kind of acts like a conditional breakpoint if some_condition is true. You can use a conditional breakpoint inside the debugger, but it can be slow and for me historically unreliable, but this little snippet gives you your own conditional breakpoint that works without fail.

Just make sure to remove the code before the PR next time!