Code to logging ratio? [closed]

Answer 1

I personally believe that first of all there is no hard and fast rule. I have some applications that log a LOT, in and out of methods, and status updates through the middle. These applications though are scheduled processes, run hands off, and the logs are parsed by another application that stores success/failure.

I have found that in all reality, many user applications don't need large amounts of logging, as really if issues come up you will be debugging to trace the values there. Additionally you typically don't need the expense of logging.

However, it really depends on the project.

Answer 2

I find that logging is much less necessary since I've started using TDD. It makes it much easier to determine where bugs lie. However, I find that logging statements can help understand what's going on in code. Sure, debuggers help give you a low-level idea of what's happening. But I find it easier when I can match a line of output to a line of code if I want to get a high level view of what's happening..

However, one thing that I should add is this: make sure your log statements include the module that the log statement is in! I can't count the number of times I've had to go back through and find where a log statement actually lies.

Answer 3

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.

Answer 4

That much logging is not necessary. There's no reason (in production) to know when each method starts and ends. Maybe you need that on certain methods, but having that much noise in the log files makes them nearly impossible to analyze effectively.

You should log when important things happen such as errors, user logins (audit log), transactions started, important data updated... so on and so forth. If you have a problem that you can't figure out from the logs, then you can add more to it if necessary... but only if necessary.

Also, just for your information, the adding logging in at compile time would be an example of what is called Aspect Oriented Programming. Logging would be the "cross cutting concern".

Answer 5

I think another factor is the toolset/platform being used and the conventions that come with it. For example, logging seems to be quite pervasive in the J(2)EE world, whereas I can't remember ever writing a log statement in a Ruby on Rails application.

Answer 6

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.