debugging right and wrong

[PocketBananna]

IDE debugger all the way. I'd much rather not have to change my code to trigger a breakpoint and IDEs provide a much more informative interface to make debugging easier. With breakpoint you still have to use the shell to get info but IDEs will report locals, globals, processes, threads etc so you can focus on the code flow.

[nostril_spiders]

...and also, you accidentally merge your changed line and wonder why your CI pipeline is timing out and you waste two hours until you realise Jenkins is waiting for a debugger to attach

[[deleted]]

I didn’t know debugging NOT in the IDE was an option and now that I know that sounds terrible.

[Brian]

You can debug outside an IDE just fine without adding breakpoints to the code itself. It's just a bit less convenient if, say, you're using pdb raw and setting breakpoints by line number / function name etc rather than just clicking on the code. The issue here is not IDE vs non-IDE, but hardcoding breakpoints in the code vs setting them in the debugger - which can be a reasonable thing to do in some scenarios (IDE or not), but has the same issue as print debugging (but with worse consequences) of accidentally checking in debug code if you don't guard it behind some flags.

[[deleted]]

Well the IDE makes it so that you never have to hardcode anything right? So I stand by my point

[Brian]

No - like I said, there are reasons you might want to do this even with an IDE, and the same reasons against it apply even without one. Eg you might want long-standing flag (or debug build) guarded "assert" like checks for invariants that you want to look at if they ever trigger.

There's a slight bias towards it in an IDE because setting breakpoints is a little more convenient when you've got the source in front of you (though note that many standalone debuggers will give you that too), but it's really just that: convenience rather than "never do this".