Is it a good practice to log all methods for debugging purpose (for tracing program flow)? [closed]

问题

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

回答1:

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:

Yes: if you have implemented it, the trace logging information is useful.
Yes: you can turn the trace logging off.
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.
No: there is a runtime overhead for logging ... even if the logging is disabled with a runtime guard on the logging statement².
No: the extra logging statements at the start and end of each method are "clutter" that make the code harder to read.
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?)
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.}

回答2:

It is quite efficient but at specific instances,taking that there are multiple threads it would actually cause devastating effect to system resources especially if you're logging to a single file. But that can be solved by reducing the logging to specific threads which can be switched at runtime.
my implementation would be:-



     class Tracer{

    void informCall(Object...callArgs){

      meth=TraceUtils.getPreviousMethod();

      if(noCondition||tracerCodition.trace(Trace.getCallerStackTraceElement())){
       //since trace method can know which thread we are in that is not a necessary argument

       TraceLogger.inform(TraceType.Method,meth.traceString()+"/nargs:/n"+TraceUtils.argsString(callArgs));
       }

     }

    }

Note: specifying a condition for tracing increases the efficiency of debugging and also concentrates the search at specific points for example maybe a method under tracing is set to execute till a certain condition is reached if this particular method terminates too fast then it will mean that tracing will not be efficient especially in a situation where there is an intentional race condition of resources or logs are written to file but setting a trace condition to trace only a specific number of calls of a method or at certain intervals of time it would help increase efficiency.

来源：https://stackoverflow.com/questions/55436550/is-it-a-good-practice-to-log-all-methods-for-debugging-purpose-for-tracing-prog

标签

java

android

performance

logging