为什么在IDE中调试更好？ [英] Why is debugging better in an IDE?
问题描述
打印语句 我尊重许多人说我的技术是原始的，在IDE中使用一个真正的调试器好多了。然而从我的观察来看，IDE用户似乎没有比使用我的石刀和熊皮更快或更成功地调试。我真诚地开始学习正确的工具，我从来没有看到使用可视化调试器的引人注目的优势。
此外，我从来没有阅读过教程或这本书显示了如何使用IDE进行有效的调试，超出了如何设置断点和显示变量内容的基础知识。
我缺少什么？什么使IDE调试工具比周到使用诊断打印语句更有效？
你可以建议资源（教程，书籍，截屏），显示更精细的IDE调试技巧？
甜蜜的答案！非常感谢大家花时间。很明亮我投了赞成票，不投票。
一些值得注意的点：
- 调试器可以帮助我做广告检查或更改变量，代码或运行时环境的任何其他方面，而手动调试需要我停止，编辑和重新执行应用程序（可能需要重新编译）。
- 调试器可以附加到正在运行的进程或使用崩溃转储，而通过手动调试，需要复制缺陷的步骤。
- 调试器可以显示复杂的数据结构，多线程环境或完整的运行时堆栈。
- 调试器提供了许多方法来减少时间和重复工作来执行几乎任何调试任务。
- 可视化调试器和控制台调试器非常有用，并且具有许多共同特性。
- 集成到IDE中的可视化调试器还可以方便地访问智能编辑和IDE的所有其他功能，在单一的集成开发环境（因此名称）。
一些IDE调试器可以在代码中为您提供跟踪消息的一些功能的示例：
- 查看调用堆栈，为您提供当前堆栈框架的上下文。
- 进入库，您不能为了添加跟踪（假设您可以访问调试符号）重新编译
- 在程序运行时更改变量值
- 编辑并继续 - 更改代码运行的能力，并立即看到结果e更改
- 可以观看变量，查看更改时间
- 能够跳过或重复代码段，以了解代码的执行情况。
- 实时检查内存
- 提醒您当某些异常被抛出时，即使它们被应用程序处理。
- 条件断点仅在特殊情况下停止应用程序，以便您分析堆栈和变量。
- 在多线程应用程序中查看线程上下文，这可能难以实现跟踪（因为来自不同线程的跟踪将在输出中交错）。
总之，打印语句（通常） 静态，如果您的原始语句不够详细，则需要重新编译以获取其他信息。 IDE会删除这个静态屏障，在您的指尖上提供一个动态工具包。
当我第一次开始编码时，我无法理解与调试器的大问题是，我以为我可以实现任何跟踪（授予，这是在unix，调试器是GDB）。但是，一旦学习如何正确使用图形调试器，就不想再回到打印语句。
I've been a software developer for over twenty years, programming in C, Perl, SQL, Java, PHP, JavaScript, and recently Python. I've never had a problem I could not debug using some careful thought, and well-placed debugging print statements.
I respect that many people say that my techniques are primitive, and using a real debugger in an IDE is much better. Yet from my observation, IDE users don't appear to debug faster or more successfully than I can, using my stone knives and bear skins. I'm sincerely open to learning the right tools, I've just never been shown a compelling advantage to using visual debuggers.
Moreover, I have never read a tutorial or book that showed how to debug effectively using an IDE, beyond the basics of how to set breakpoints and display the contents of variables.
What am I missing? What makes IDE debugging tools so much more effective than thoughtful use of diagnostic print statements?
Can you suggest resources (tutorials, books, screencasts) that show the finer techniques of IDE debugging?
Sweet answers! Thanks much to everyone for taking the time. Very illuminating. I voted up many, and voted none down.
Some notable points:
- Debuggers can help me do ad hoc inspection or alteration of variables, code, or any other aspect of the runtime environment, whereas manual debugging requires me to stop, edit, and re-execute the application (possibly requiring recompilation).
- Debuggers can attach to a running process or use a crash dump, whereas with manual debugging, "steps to reproduce" a defect are necessary.
- Debuggers can display complex data structures, multi-threaded environments, or full runtime stacks easily and in a more readable manner.
- Debuggers offer many ways to reduce the time and repetitive work to do almost any debugging tasks.
- Visual debuggers and console debuggers are both useful, and have many features in common.
- A visual debugger integrated into an IDE also gives you convenient access to smart editing and all the other features of the IDE, in a single integrated development environment (hence the name).
Some examples of some abilities that an IDE debugger will give you over trace messages in code:
- View the call stack at any point in time, giving you a context for your current stack frame.
- Step into libraries that you are not able to re-compile for the purposes of adding traces (assuming you have access to the debug symbols)
- Change variable values while the program is running
- Edit and continue - the ability to change code while it is running and immediately see the results of the change
- Be able to watch variables, seeing when they change
- Be able to skip or repeat sections of code, to see how the code will perform. This allows you to test out theoretical changes before making them.
- Examine memory contents in real-time
- Alert you when certain exceptions are thrown, even if they are handled by the application.
- Conditional breakpointing; stopping the application only in exceptional circumstances to allow you to analyse the stack and variables.
- View the thread context in multi-threaded applications, which can be difficult to achieve with tracing (as the traces from different threads will be interleaved in the output).
In summary, print statements are (generally) static and you'll need to re-compile to get additional information if your original statements weren't detailed enough. The IDE removes this static barrier, giving you a dynamic toolkit at your fingertips.
When I first started coding, I couldn't understand what the big deal with debuggers was and I thought I could achieve anything with tracing (granted, that was on unix and the debugger was GDB). But once you learn how to properly use a graphical debugger, you don't want to go back to print statements.
这篇关于为什么在IDE中调试更好？的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！
