Debugging 如何一致地组织代码进行调试？
当你在一个需要调试的大项目中工作时（就像每个项目一样），你会意识到在IDE的内置调试器出现之前人们是多么喜欢“printf”。我的意思是说Debugging 如何一致地组织代码进行调试？,debugging,logging,oop,coding-style,Debugging,Logging,Oop,Coding Style,当你在一个需要调试的大项目中工作时（就像每个项目一样），你会意识到在IDE的内置调试器出现之前人们是多么喜欢“printf”。我的意思是说 有时需要将变量值呈现到屏幕上（特别是用于交互式调试） 有时需要将它们记录到一个文件中 有时，您必须将可见性（使其公开）仅更改为另一个类才能访问它（例如，记录器或渲染器） 有时，您需要在成员中保存上一个值，以便在调试期间将其与新值进行对比 当一个项目变得庞大，有很多人在工作时，所有这些特定于调试的代码都会变得混乱，很难与普通代码区分开来。对于那些不得不更
- 有时需要将变量值呈现到屏幕上（特别是用于交互式调试）
- 有时需要将它们记录到一个文件中
- 有时，您必须将可见性（使其公开）仅更改为另一个类才能访问它（例如，记录器或渲染器）
- 有时，您需要在成员中保存上一个值，以便在调试期间将其与新值进行对比
谢谢。我会投票支持你所说的友好追踪者课程。这个类将保持所有这些集中化，甚至可能允许您动态更改调试/日志策略
我会避免使用宏之类的东西，因为这是一个编译器技巧，而不是真正的OO。通过抽象调试/日志的概念，您有机会用它做很多事情，包括在需要时使其成为无操作。日志还是调试？我相信设计良好且经过适当单元测试的应用程序不需要永久性地进行调试。另一方面，日志记录在查找bug和审计程序操作方面都非常有用。我不想介绍从其他地方可以获得的大量信息，而是要为您指出可以使用的具体实现或合理设计日志基础结构的模板。我认为避免直接使用System.outs/printfs，而是使用（甚至是自定义）日志类尤其重要。这至少为所有日志提供了一个集中的kill开关（减去Java中的调用成本） 让日志类具有info/warn/error/caveat等也很有用 我会注意错误级别、用户ID、元数据等，因为人们并不总是添加它们
此外，我所看到的最常见的问题之一是，人们在调试某些东西时在代码中放入临时printf，然后忘记将它们放在何处。我使用一个工具来跟踪我所做的每件事，这样我就可以快速识别我最近编辑的所有内容，从一个抽象的检查点开始删除它们。但是，在大多数情况下，您可能希望对可以签入源代码管理的调试代码提出特殊规则 不提交调试代码，只提交调试工具 Loggin Oto在执行处理例程等方面有着天然的地位。此外，在一些常用的API中放置一些位置良好的日志语句也有助于调试 就像一个日志语句记录从系统执行的所有SQL。在VB6中
Debug.Print
#If <some var set in the project properties>
'debugging code
#End If
是的，它确实会变得混乱，是的，我希望有更好的方法。我们通常开始使用一个静态类来编写跟踪消息。它非常基本，仍然需要执行方法的调用，但它符合我们的目的 在.NET世界中，已经有相当数量的内置跟踪信息可用，因此我们不需要担心调用了哪些方法或执行时间是多少。这些更适用于代码执行过程中发生的特定事件
如果您的语言不支持通过其跟踪构造对消息进行分类，则应该将其添加到跟踪代码中。能够识别不同级别的重要性和/或功能领域的东西是一个很好的开始。只要避免通过修改代码来检测代码。学习使用调试器。使日志记录和错误处理变得容易。请看一看调试/记录代码确实可能具有侵入性。在我们的C++项目中，我们将宏调试/日志代码打包在宏中，非常类似于断言。我经常发现日志记录在较低级别的组件中最有用，因此它不必到处都有 同意和不同意的其他答案有很多：）拥有调试/日志代码是解决问题的非常有价值的工具。在Windows中，有许多技术—主要有两种：
- 广泛使用已检查（DBG）构建断言，并对DBG构建进行大量测试
- ETW在我们称之为“fre”或“零售”构建中的使用
Dim Trc as Std.Traces
Trc.Tracing = True
Trc.Tracefile = "c:\temp\app.log"
Trc.Trace 'with no argument stores date stamp
Trc.Trace "Var=" & var