Should I Leave My Logging in the Code?

Some topics are guaranteed to create an argument among developers, and logging is one of them. If you�ve added logging to the code to help while tracking down a problem, it�s tempting to leave this instrumentation in place so that you can find the problem again quickly if it happens again. This is especially true if you�re using a logging framework that allows it to be enabled and disabled easily. What�s not to like?

So, why the controversy? Detractors will tell you the following:

� Logging obscures the code, making it difficult to see the wood for the trees.

� Logging can suffer from the same problems as comments�as the code evolves, often the logging isn�t updated to match, meaning that you can�t trust what it says and making it worse than useless.

� No matter how much logging you add, it�s never what you need. The next time you find yourself debugging in that area, you�ll just have to add more, and if you leave it in the code when you�re done, you just exacerbate the first two problems.

As with most disputes of this nature, the answer is to be pragmatic. Logging is a useful tool, but it can be overused. Consider implementing permanent logging if you believe that it will add value, but be disciplined about how you do so. Make sure that your logging is up-to-date and agrees with the code and that you don�t add it for its own sake.

As a general rule, the most useful logging is at the highest (strategic) level�a record of what happened, such as the access log generated by an HTTP server, for example. Lower level, more tactical logging can be of questionable long-term value, so make sure you know what it�s giving you before you decide to add it.

If you find that logging is getting in the way but you don�t want to lose its benefits, you might want to look at aspect-oriented programming, which may give you a way to separate it from the main body of the code (a good reference is Ramnivas Laddad. AspectJ in Action: Practical Aspect-Oriented Programming. Manning Publications Co., 2003.)

Source of Information : Paul Butcher - Debug it Find repair and prevent bugs