Why is debugging better in an IDE? [closed]

Answer 1

• An IDE debugger lets you change the values of variables at run-time.

• An IDE debugger lets you see the value of variables you didn't know you wanted to see when execution began.

• An IDE debugger lets you see the call stack and examine the state of the function passed weird values. (think this function is called from hundreds of places, you don't know where these weird values are coming from)

• An IDE debugger lets you conditionally break execution at any point in code, based on a condition, not a line number.

• An IDE debugger will let you examine the state of the program in the case of an unhandled exception instead of just crapping out.

Answer 2

In my experience, simple printouts have one huge advantage that no one seems to mention.

The problem with an IDE debugger is that everything happens at real time. You halt the program at a certain time, then you step through the steps one at a time and it is impossible to go back if you suddenly want to see what happened before. This is completley at odds with how our brain works. The brain collects information, and gradually forms an oppinion. It might be necessary to iterate the events several times in doing so, but once you have stepped past a certain point, you cannot go back.

In contrast to this, a selected series of printouts/logging gives you a "spatial projection of the temporal events". It gives you a complete story of what happened, and you can go back and fourth several times very easily by just scrolling up and down. It makes it easy to answer questions like "did A occur before B happened". It can make you see patterns you wernt even looking for.

So in my experience. IDE and debuggers are fantastic tools to solve simple problems when something in one single call-stack went wrong, and explore the current state of the machine at a certain crash.

However, when we approach more difficoult problems where gradual changing of state is involved. Where for example one algorithm corrupted a data structure, that in turn caused anohter algorithm to fail. Or if we want to answer questions like "how often do this happen", "do things happen in the order and in the way as I imagine them to happen". etc. Then the "old fashined" logging/printout technique has a clear advantage.

The best things is to use either technique when it is most suitable, for example use logging/printouts to get to some bugs, and pause at a breakpoint where we need to explore the current state more in detail.

There are also hybrid approaches. For example, when you do console.log(object) you get a data-structure widget in the log that you can expand and explore more in detail.This is many times a clear advantage over a "dead" text log.

Answer 3

As someone said above: Debugger != IDE.

gdb and (back in the day) TurboDebugger (stand-alone) work just fine for the languages they support[ed], thank you. (or an even older technology: Clipper debugger linked into the xBase executable itself) -- none of these required an IDE

Also, though C/++ coding is more rare, printf statements sometimes mask off the very bug you are trying to find! (initialization problems in auto vars on the stack, for instance, or memory allocation/alignment)

Finally, as others stated, you can use both. Some real-time-ish problems almost require a print, or at least a judicious "*video_dbg = ( is_good ? '+' : '-');" somewhere into video memory. My age is showing, this was under DOS :-)

TMTOWTDI

Answer 4

Because debugging multi-threaded applications with print statements will drive you bananas. Yes you can still do it with print statements but you'd need a lot of them and unravelling the sequential print out of statements to emulate the multi-threaded executiong would take a long long time.

Human brains are only single-threaded unfortunately.

Answer 5

With an IDE debugger you can see the values of ALL the variables in the current scope (all the way up the call stack) whenever you halt execution.

Print statements can be great but dumping so much information to the screen at any given place can produce a whole lot of print statements.

Also, many IDE debuggers let you type in and evaluate methods, and evaluate members while you are halted, which further increases the amount of print statements you'd have to do.

I do feel that debuggers are better for some languages than for others however...

My general opinion is that IDE debuggers are absolutely, amazingly wonderful for managed languages like Java or C#, are fairly useful for C++, and are not very useful for scripting languages like Python (but it could be that I just haven't tried a good debugger for any scripting languages yet).

I absolutely love the debugger in IntelliJ IDEA when I do Java development. I just use print statements when I use Python.

Answer 6

• Print statements all through your code reduces readability.
• Adding and removing them for debug purposes only is time consuming
• Debuggers track the call stack making it easy to see where you are
• Variables can be modified on the fly
• Adhoc commands can be executed during a pause in execution to assist diagnosing
• Can be used IN CONJUNCTION with print statements : Debug.Write("...")