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

There is actually a nice library for adding in logging after the fact as you say, PostSharp. It lets you do it via attribute-based programming, among many other very useful things beyond just logging.

I agree that what you say is a little excessive for logging.

Some others bring up some good points, especially the banking scenario and other mission critical apps. It may be necessary for extreme logging, or at least be able to turn it on and off if needed, or have various levels set.

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

In my line of work, I write a lot of Windows services. For me, logging isn't a luxury; it's actually my only UI. When we deploy to production, we lose access to debugging and even the databases to which our services write and without logging we would have no way of knowing any specifics of issues that arise.

Having said that, I do believe that a concise logging style is the best approach. Log messages tend to be limited to the business logic of the application such as "received message from account xxx" than "entered function yyy". We do log exceptions, thread starts, echoing of environment settings and timings. Beyond that, we look to the debugger to identify logical errors in the development and QA phases.

Answer 4

How many of those lines are logging by default? I've worked on a system very much like what you describe - just booting it up would cause over 20MB of logs to be written if logging was cranked way up, but even debugging we didn't turn it all the way up for all modules. By default it would log when a module of code was entered, and major system events. It was great for debugging since QA could just attach a log to a ticket, and even if it wasn't reproducible you could see what was going on when the problem happened. If you have serious multithreading going on then logging is still better than any IDE or debugger I've worked with.

Answer 5

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

Yes, absolutely, although the mistake that many unskilled developers make is to try to fix bugs using the wrong method, usually tending towards logging when they should be debugging. There is a place for each, but there are at least a few areas where logging will almost always be necessary:

• For examining problems in realtime code, where pausing with the debugger would effect the result of the calculation (granted, logging will have a slight impact on timing in a realtime process like this, but how much depends greatly on the software)
• For builds sent to beta testers or other colleagues who may not have access to a debugger
• For dumping data to disk that may not be easy to view within a debugger. For instance, certain IDE's which cannot correctly parse STL structures.
• For getting a "feel" of the normal flow of your program
• For making code more readable in addition to commenting, like so:

// Now open the data file
fp = fopen("data.bin", "rb");

The above comment could just as easily be placed in a logging call:

const char *kDataFile = "data.bin";
log("Now opening the data file %s", kDataFile);
fp = fopen(kDataFile, "rb");

That said, you are in some ways correct. Using the logging mechanism as a glorified stack-trace logger will generate very poor quality logfiles, as it doesn't provide a useful enough failure point for the developer to examine. So the key here is obviously the correct and prudent use of logging calls, which I think boils down to the developer's discretion. You need to consider that you're essentially making the logfiles for yourself; your users don't care about them and will usually grossly misinterpret their contents anyways, but you can use them to at least determine why your program misbehaved.

Also, it's quite rare that a logfile will point you to the direct source of a certain bug. In my experience, it usually provides some insight into how you can replicate a bug, and then either by the process of replicating it or debugging it, find the cause of the problem.

Answer 6

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.