Application logging best practices - How to manage logging statements strewn all over your code?

Question

I just read this post on Stackoverflow and there was one aspect of logging that I didn't see addressed. Independent of the specific logging framework, how do folks handle the fact that most approaches result in logging/trace statements placed all throughout your code, making it more difficult to actually see the meat and potatoes of the code base. Is this just the reality of life or are there techniques/mechanisms to address this, such as perhaps:

A means of selectively hiding and showing all the logging and tracing statements
Use of class or method attributes which enable logging
...?

I am working in .NET/Visual studio but I suppose my question applies in general.

Use a logging aspect of some sort? I assume AOP is provided by some .net library or other.. — Paul Hicks, Jun 19 '15 at 01:38

score 1 · Accepted Answer · answered Jun 20 '15 at 22:32

Ultimately, if you want logging/tracing in your app, then there is no escaping having that code in your source.

In theory you could use aspect oriented programming (AOP) tools such as PostSharp to hook in the logging/tracing calls, but regards calling tracing in methods e.g.

public void Foo()
{
    Trace.WriteLine("About to call web service");

    Trace.WriteLine("Updating database with data");
}

There is not much you can do to "hide" those from view. In theory you could have a method that is decorated with the Conditional attribute...

[Conditional("DEBUG")]
public void Trace(string message)
{
    Trace.WriteLine(message);
}

...so that the method, and calls to it, is removed from release builds. But that isn't very helpful if you need that logging for a release build of your code!

Application logging best practices - How to manage logging statements strewn all over your code?

1 Answers1