进行调试的方法有很多种,使用调试器就是其中一种,但对于谦虚、懒惰的程序员来说,最简单的方法就是在代码中添加一堆打印语句。
IE
def foo(x):
print 'Hey wow, we got to foo!', x
...
print 'foo is returning:', bar
return bar
这种调试方式有合适的名称吗?
进行调试的方法有很多种,使用调试器就是其中一种,但对于谦虚、懒惰的程序员来说,最简单的方法就是在代码中添加一堆打印语句。
IE
def foo(x):
print 'Hey wow, we got to foo!', x
...
print 'foo is returning:', bar
return bar
这种调试方式有合适的名称吗?
是的 - 它被称为printf()
调试,以无处不在的 C 函数命名:
用于描述通过在程序流的关键点插入输出或多或少精心选择的状态信息的命令完成的调试工作,观察该信息并根据该信息推断出什么错误。
毫无疑问,其他语言的本地用户通过他们选择的编码平台可用的默认打印/日志/跟踪命令来引用它,但我听说过在许多其他语言中用于引用这种技术的“printf()”名称可能是因为它的历史:虽然 BASIC 和 FORTRAN 有基本但可用PRINT
的命令,但 C 通常需要更多的工作来格式化各种数据类型:printf()
是(并且通常仍然是)迄今为止最方便的方法达到此目的,提供了许多内置的格式化选项。它的表亲,fprintf()
,采用另一个参数,要写入的流:这允许仔细的“调试器”将诊断信息定向到stderr
(可能自身重定向到日志文件),同时保持程序的输出不受破坏。
尽管现代调试软件的用户经常看不起 printf() 调试,但它继续证明自己不可或缺:用于 Firefox Web 浏览器的广受欢迎的 FireBug 工具(以及现在可用于其他浏览器的类似工具)是围绕控制台窗口构建的网页脚本可以记录错误或包含格式化数据的诊断消息。
我听说它叫做Caveman Debugging
我认为下面的引用是恰当的:
“最有效的调试工具仍然是仔细考虑,再加上明智地放置打印语句。”
— Brian Kernighan,“Unix 初学者”(1979 年)
我称之为追踪。
我和我的队友称之为“Oldschool Debuging”。
你的裤子调试:)
当您在嵌入式系统上时,当您处于最前沿并且您正在编码的语言还没有调试器时,当您的调试器行为异常并且您想要恢复一些理智时,您想要了解重入是如何在多线程代码中工作的,......
我称之为“嗨,妈妈”编程。
我还从 VB 人群中听到了“MessageBox 调试”一词来指代这种“调试”的“风格”。
在与探索性编程相同的意义上,我喜欢称它为探索性调试。当调试器不足以检查程序中的复杂类型或单独调用辅助函数时,或者您对错误了解不足而无法直接使用所述功能时,就会出现这种情况。
我嵌入式系统通常是检测代码的唯一方法。不幸的是,打印需要时间并影响系统的实时流程。因此,我们还通过“跟踪”进行检测,其中有关系统状态的信息(函数入口退出等)被写入内部缓冲区,以便稍后转储和解析。真正的嵌入式程序员可以通过闪烁 LED 进行调试;)
我听说有人使用“古腾堡调试”来纪念印刷机的发明者。
我将其简称为“日志记录”。
我通常将其称为跟踪。
请注意,在 Visual Studio 中,您可以设置仅添加跟踪的断点。右键单击断点,选择“当命中...”并选中“打印消息”选项。
此外,在 .Net 中,您可以添加调试语句(我认为它实际上是 Debug.WriteLine)以输出到控制台。这些语句仅包含在调试版本中 - 当您进行发布版本时,编译器会自动将它们排除在外。
经典调试
详细调试!
(良好的日志记录对于在运行的生产系统中调试问题非常有价值。许多无用的冗长打印语句不是,但是当重要或意外发生时记录一些有趣的事情非常重要。如果您知道如何调试问题的唯一方法就是使用作为调试器,当您构建的服务对您的某些用户而言已损坏但您无法在本地重现问题时,您会发现自己处于非常紧张的境地。)
手动断言?调试器恐惧症?
我一直以“快速和肮脏的调试”这个术语来了解它,或者简称为“肮脏的调试”。