Code to logging ratio? [closed]

Question

What is the ideal code to logging ratio? I'm not used to writing logs as most of the applications I've developed have not had much logging.

Recently though I've changed job, and I've noticed that you can't see the application code for the calls to log4net. I appreciate that this is useful but surely having too many debug statements is just as bad as not having any at all?

There are logging statements that tell you when every method starts and finishes and what they are returning. and when pretty much anything is done.

Would it not be easier to have some addon that used reflection to add the logging statements in at compile time so they didn't get in the way as you were trying to look at the code?

Also in these days of powerful IDEs and remote debugging is that much logging really nescisary?

Answer 1

Since log4net does a great job at not clogging up the resources, I tend to be a little verbose on logging because when you have to change to debug mode, the more info you have, the better. Here's what I typically log:

DEBUG Level

• Any parameters passed into the method
• Any row counts from result sets I retrieve
• Any datarows that may contain suspicious data when being passed down to the method
• Any "generated" file paths, connection strings, or other values that could get mungled up when being "pieced together" by the environment.

INFO Level

• The start and end of the method
• The start and end of any major loops
• The start of any major case/switch statements

ERROR Level

• Handled exceptions
• Invalid login attempts (if security is an issue)
• Bad data that I have intercepted forreporting

FATAL Level

• Unhandled exceptions.

Also having a lot of logging details prevents me from asking the user what they were doing when they got the error message. I can easily piece it together.

Answer 2

Complete log files are amazingly useful. Consider a situation where your application is deployed somewhere like a bank. You can't go in there and debug it by hand and they sure aren't going to send you their data. What you can get is a complete log which can point you to where the problem occured. Having a number of log levels is very helpful. Normally the application would run in a mode such that it only reports on fatal errors or serious errors. When you need to debug it a user can switch on the debug or trace output and get far more information.

The sort of logging you're seeing does seem excessive but I can't really say it is for certain without knowing more about the application and where it might be deployed.