其他语言的本机用户无疑可以参考它通过可用于其选择的编码平台的默认打印/日志/或跟踪命令来实现，但我听说过“printf()”名称在除 C 之外的许多语言中用来指代此技术。也许这是由于它的历史：虽然 BASIC 和 FORTRAN 具有基本但可用的 PRINT 命令，但 C 通常需要更多的工作来格式化各种数据类型：printf() 曾经（并且通常仍然如此） 迄今为止达到此目的最方便的方法是提供许多内置格式选项。 它的表亲 fprintf() 采用另一个参数，即要写入的流：这允许仔细的“调试器”将诊断信息定向到 stderr （可能本身会重定向到日志文件），同时保持程序的输出不被破坏。
尽管经常被现代调试软件的用户轻视，但 printf() 调试仍然证明了自己不可或缺：用于 Firefox Web 浏览器的广受欢迎的 FireBug 工具（以及现在可用于其他浏览器的类似工具）是围绕一个控制台窗口构建的，在该窗口中网页脚本可以记录包含格式化数据的错误或诊断消息。
Yes - it's known as printf() debugging, named after the ubiquitous C function:
Used to describe debugging work done by inserting commands that output more or less carefully chosen status information at key points in the program flow, observing that information and deducing what's wrong based on that information.
Native users of other languages no doubt refer to it by the default print / log / or trace command available for their coding platform of choice, but i've heard the "printf()" name used to refere to this technique in many languages other than C. Perhaps this is due to its history: while BASIC and FORTRAN had basic but serviceable PRINT commands, C generally required a bit more work to format various data types: printf() was (and often still is) by far the most convenient means to this end, providing many built-in formatting options. Its cousin, fprintf(), takes another parameter, the stream to write to: this allowed a careful "debugger" to direct diagnostic information to stderr (possibly itself redirected to a log file) while leaving the output of the program uncorrupted.
Although often looked down on by users of modern debugging software, printf() debugging continues to prove itself indispensable: the wildly popular FireBug tool for the Firefox web browser (and similar tools now available for other browsers) is built around a console window into which web page scripts can log errors or diagnostic messages containing formatted data.
When you're on an embedded system, when you're at the bleeding edge and the language you're coding in doesn't have a debugger yet, when your debugger is behaving strangely and you want to restore some sanity, and you want to understand how re-entrancy is working in multi-threaded code,....
In the same sense as exploratory programming, I like calling it exploratory debugging. This follows when the debugger is not powerful enough to examine complex types in the program, or invoke helper functions separately, or you just don't know enough about a bug to use said features directly.
对于嵌入式系统来说，它通常是检测代码的唯一方法。 不幸的是打印需要时间并且影响系统的实时流程。 因此，我们还通过“跟踪”进行检测，其中有关系统状态（函数入口出口等）的信息被写入内部缓冲区，以便稍后转储和解析。 真正的嵌入式程序员可以通过 LED 闪烁来进行调试；）
I embedded systems its often the only method to instrument the code. Unfortunately printing takes time and effects the real-time flow of the system. So we also instrument via "tracing" where information about the state of the system (function entry exit etc) is written to a internal buffer to be dumped and parsed later. Real embedded programmers can debug by blinking an LED ;)
请注意，在 Visual Studio 中，您可以设置仅添加跟踪的断点。 右键单击断点，选择“当命中...”并选中“打印消息”选项。
I usually refer to it as tracing.
Note that in Visual Studio you can set breakpoints which just add tracing. Right click on a breakpoint, select "when hit..." and check the "Print a message" option.
Also, in .Net you can add debugging statements (I think it actually is Debug.WriteLine) to output to the console. These statments are only included in debug builds - the compiler will automatically leave them out when you do a release build.
(Good logging is incredibly valuable for debugging problems in running production systems. Lots of useless verbose print statements aren't, but logging something interesting when something important or unexpected occurred is incredibly important. If the only way you know how to debug problems is with a debugger, you're going to find yourself in quite the tight spot when the service you've built is broken for some of your users but you can't reproduce the problem locally.)
发布评论
评论（19）
是的 - 它被称为
printf()调试，以无处不在的 C 函数命名：-- printf()debugging@everything2
其他语言的本机用户无疑可以参考它通过可用于其选择的编码平台的默认打印/日志/或跟踪命令来实现，但我听说过“printf()”名称在除 C 之外的许多语言中用来指代此技术。也许这是由于它的历史：虽然 BASIC 和 FORTRAN 具有基本但可用的
PRINT命令，但 C 通常需要更多的工作来格式化各种数据类型：printf()曾经（并且通常仍然如此） 迄今为止达到此目的最方便的方法是提供许多内置格式选项。 它的表亲fprintf()采用另一个参数，即要写入的流：这允许仔细的“调试器”将诊断信息定向到stderr（可能本身会重定向到日志文件），同时保持程序的输出不被破坏。尽管经常被现代调试软件的用户轻视，但 printf() 调试仍然证明了自己不可或缺：用于 Firefox Web 浏览器的广受欢迎的 FireBug 工具（以及现在可用于其他浏览器的类似工具）是围绕一个控制台窗口构建的，在该窗口中网页脚本可以记录包含格式化数据的错误或诊断消息。
Yes - it's known as
printf()debugging, named after the ubiquitous C function:-- printf() debugging@everything2
Native users of other languages no doubt refer to it by the default print / log / or trace command available for their coding platform of choice, but i've heard the "printf()" name used to refere to this technique in many languages other than C. Perhaps this is due to its history: while BASIC and FORTRAN had basic but serviceable
PRINTcommands, C generally required a bit more work to format various data types:printf()was (and often still is) by far the most convenient means to this end, providing many built-in formatting options. Its cousin,fprintf(), takes another parameter, the stream to write to: this allowed a careful "debugger" to direct diagnostic information tostderr(possibly itself redirected to a log file) while leaving the output of the program uncorrupted.Although often looked down on by users of modern debugging software, printf() debugging continues to prove itself indispensable: the wildly popular FireBug tool for the Firefox web browser (and similar tools now available for other browsers) is built around a console window into which web page scripts can log errors or diagnostic messages containing formatted data.
我认为下面的引用是恰当的：
I thought the following quote would be apropos:
我听说它被称为穴居人调试
I've heard it called Caveman Debugging
我称之为追踪。
I call it Tracing.
我和我的队友称之为“老派调试”。
me and my team mates calling it "Oldschool Debuging".
凭感觉调试 :)
当您在嵌入式系统上时，当您处于最前沿并且您正在编码的语言还没有调试器时，当您的调试器行为很奇怪，你想恢复一些理智，你想了解重入在多线程代码中是如何工作的，......
Seat of your pants debugging :)
When you're on an embedded system, when you're at the bleeding edge and the language you're coding in doesn't have a debugger yet, when your debugger is behaving strangely and you want to restore some sanity, and you want to understand how re-entrancy is working in multi-threaded code,....
我称之为“嗨，妈妈”编程。
I call this "Hi, Mom" programming.
我还从 VB 人群中听说过术语“MessageBox 调试”来指代这种“调试”的“风格”。
I have also heard the term "MessageBox debugging" from the VB crowd to refer to this 'style' of 'debugging'.
与探索性编程一样，我喜欢称之为探索性调试 >。 当调试器不够强大，无法检查程序中的复杂类型，或单独调用辅助函数，或者您对错误不够了解而无法直接使用所述功能时，就会出现这种情况。
In the same sense as exploratory programming, I like calling it exploratory debugging. This follows when the debugger is not powerful enough to examine complex types in the program, or invoke helper functions separately, or you just don't know enough about a bug to use said features directly.
对于嵌入式系统来说，它通常是检测代码的唯一方法。 不幸的是打印需要时间并且影响系统的实时流程。 因此，我们还通过“跟踪”进行检测，其中有关系统状态（函数入口出口等）的信息被写入内部缓冲区，以便稍后转储和解析。 真正的嵌入式程序员可以通过 LED 闪烁来进行调试；）
I embedded systems its often the only method to instrument the code. Unfortunately printing takes time and effects the real-time flow of the system. So we also instrument via "tracing" where information about the state of the system (function entry exit etc) is written to a internal buffer to be dumped and parsed later. Real embedded programmers can debug by blinking an LED ;)
我听说过“古腾堡调试”被使用，以纪念那个人发明了印刷机。
I've heard "Gutenberg debugging" being used, in the honor of the guy who invented the printing press.
我将其简单地称为“日志记录”。
I would call it simply "logging".
我通常将其称为跟踪。
请注意，在 Visual Studio 中，您可以设置仅添加跟踪的断点。 右键单击断点，选择“当命中...”并选中“打印消息”选项。
I usually refer to it as tracing.
Note that in Visual Studio you can set breakpoints which just add tracing. Right click on a breakpoint, select "when hit..." and check the "Print a message" option.
另外，在.Net中，您可以添加调试语句（我认为它实际上是Debug.WriteLine）以输出到控制台。 这些语句仅包含在调试版本中 - 当您进行发布版本时，编译器会自动将它们排除在外。
Also, in .Net you can add debugging statements (I think it actually is Debug.WriteLine) to output to the console. These statments are only included in debug builds - the compiler will automatically leave them out when you do a release build.
经典调试
Classic Debugging
详细的调试！
verbose debugging !
（良好的日志记录对于调试运行生产系统中的问题非常有价值。许多无用的冗长打印语句不是，但是当发生重要或意外的事情时记录一些有趣的内容非常重要。如果您知道如何调试问题的唯一方法是使用调试器，当您构建的服务对某些用户来说被破坏但您无法在本地重现问题时，您会发现自己陷入了困境。）
(Good logging is incredibly valuable for debugging problems in running production systems. Lots of useless verbose print statements aren't, but logging something interesting when something important or unexpected occurred is incredibly important. If the only way you know how to debug problems is with a debugger, you're going to find yourself in quite the tight spot when the service you've built is broken for some of your users but you can't reproduce the problem locally.)
手动断言？ 调试器恐惧症？
Manual Assertions? Debugger Phobia?
我一直将其称为“快速而肮脏的调试”，或者简称为“肮脏的调试”。
I have always known it by the term 'quick-and-dirty debugging', or just 'dirty debugging' in short.