记录所有方法以进行调试(跟踪程序流)是否是一种好习惯? [英] Is it a good practice to log all methods for debugging purpose (for tracing program flow)?

问题描述

我正在开发一个android应用程序代码库，其中程序员已正确记录了每种应用程序方法的开始和退出.我发现这很奇怪，但同时了解应用程序流程也非常有帮助.这种做法省去了我的很多调试工作，因为它们可以理解现有的代码流以识别错误的方法.

所以，我很好奇，以上述方式记录每个方法是一种好习惯吗?(我们总是可以设置一个标记，仅在需要时/调试时启用此类日志).

谢谢

解决方案

所以，我很好奇，以上述方式记录每种方法是一种好习惯吗?(我们总是可以放一个标记，使其仅在需要时/调试时启用此类日志).

总的来说，编号

这当然不是广泛接受的作为良好实践 ¹ .

这里有一些优点和缺点:

1. 是的:如果已实现，则跟踪日志记录信息将非常有用.

2. 是的:您可以关闭跟踪记录.

3. 否:对于非平凡的应用程序，跟踪日志记录的数量可能非常庞大.存储太多.太多分析.太多要求客户发送给您.

4. 否:即使使用日志记录语句 ² 上的运行时防护禁用了日志记录，也存在日志记录的运行时开销.

5. 否:每个方法开头和结尾的额外日志语句是混乱的"，使代码更难阅读.

6. 否:假定手动添加了额外的日志记录语句，这是额外的编程工作，并且是额外的错误源.(而且这些bug可能很难在测试中发现.您是否要编写单元测试/以检查跟踪是否已正确实施的任何内容?)

7. 否:如果代码是多线程的，跟踪调试可以更改代码的行为.例如，在非线程安全的应用程序中，打开跟踪可能导致意外同步.这可能会导致错误的应用程序的行为发生变化.c.f.Heisenbug.

最后，您的IDE调试器可以允许您记录方法的进入和退出自动执行，而无需在源代码级别执行任何操作.(当然，这对解决Heisenbug问题没有帮助；请参见上文.)

---

^{1-如果是这样，您会在许多/大多数开源代码库中看到这种做法.我不记得曾经见过它.}

^{2-如果您找到一种使用预处理器禁用它的方法，或者构建/加载时间代码注入，或者使用 if(compileTimeConstFlag)构造，则可以消除开销.但是，这样您就失去了打开和关闭跟踪的灵活性.而且对您的源代码的影响更大.}

I am working on an android application codebase where programmer has properly logged the beginning and exit of each and every method of application. I found it very odd but extremely helpful at the same time to understand the application flow. This practice saved a lot of my debugging efforts of understanding the existing code flow to identify the buggy method.

So, I am curious, is it a good practice to log every method in aforesaid manner? (we can always put a flag to only enable such logs when needed/while debugging).

Thanks

解决方案

So, I am curious, is it a good practice to log every method in aforesaid manner? (we can always put a flag to only enable such logs when needed/while debugging).

On balance, No.

It is certainly not broadly accepted as good practice¹.

Here are some pros, and cons:

1. Yes: if you have implemented it, the trace logging information is useful.

2. Yes: you can turn the trace logging off.

3. No: for a non-trivial application, the amount of trace logging could be overwhelming. Too much to store. Too much to analyse. Too much to ask a customer to send you.

4. No: there is a runtime overhead for logging ... even if the logging is disabled with a runtime guard on the logging statement².

5. No: the extra logging statements at the start and end of each method are "clutter" that make the code harder to read.

6. No: assuming the extra logging statements are added by hand, that is extra programming effort, and an extra source of bugs. (And the bugs may be hard to spot in test. Are you going to write unit tests / whatever to check that tracing has been implemented correctly?)

7. No: trace debugging can change the behavior of your code if it is multi-threaded. For example, turning on tracing can lead to serendipitous synchronization in a non-thread-safe application. This can cause the behavior of a faulty application to change; c.f. a Heisenbug.

Finally, your IDE's debugger may allow you to log the entry and exit of methods automatically without doing anything at the source code level. (Of course, this doesn't help with the Heisenbug issue; see above.)

---

^{1 - If it was, you would see this practice in many / most open-source codebases. I can't recall ever seeing it.}

^{2 - If you find a way disable it with a preprocessor, or build / load time code injection, or if (compileTimeConstFlag) constructs, you can remove the overheads. But then you lose the flexibility to turn tracing on and off. And the impact on your source code is greater.}

这篇关于记录所有方法以进行调试(跟踪程序流)是否是一种好习惯?的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！