A little more about logging

A friend of mine, who read the first article, asked me to elaborate further about good logging practices. Hence, I decide to go over some of them, point the problems and discuss the alternatives. I will try to discuss the items in the order they appeared on the article. To start this series of texts, let’s discuss about fancy logs.

Don’t be fancy: avoid formatting the messages and/or adding special characters not related to the event being logged.

As noted by Steve McConnell on the second edition of the bible of craftsmanship, Code Complete, the style is a maintenance item. Although he mentions specifically about code comments, you can infer the same about logs, after all they require maintenance as well.

Let’s explore a bit further the examples presented on the last article. If you don’t remember them, I presented one example of a poorly written log message and better alternative. They were:

• Good one: “The application has started”
• Bad one:  “****** The application has started ********”

At first sight, the bad one does not look so bad, does it? Just a few more asterisks than the good one … Well , the truth is it does. By looking at that the bad message we can spot problems that increase not only the code maintenance, but also the application management effort and its cost.

Let’s find out a little bit about them by asking a few questions. At this point I would recommend asking a colleague. If you don’t have one, try to answer the questions without looking at the messages. Ask your colleague or yourself:

• Were you able to easily identify how many asterisks are there each side of the message?
• Did you notice that one side of the message has more asterisks than the other?
• Will you be able to remember how many asterisks have you put on each side of the message 1 or 2 years from now? Specifically, will you be able to do when you have to perform an urgent maintenance on this module?
  • Will your fellow developer – on the other side of the globe, eventually – remember that in 1 or 2 weeks from now, when he has to review your code?
• Did you notice that the formatting used by aforementioned example consume 20% of the width of a standard 25×80 terminal?
• Did you notice that, for a low volume application – ~10 transactions per second – the formatting in this example, can consume an extra ~13Mb of disk space per day – or bandwidth, if you log over the network? That accounts for ~4.6 Gb a year!

There’s a good chance that at least a couple of the items in this list will go unnoticed – it’s a great thing, though, if they don’t; but that’s a subject about another article. The purpose of these questions are to show you that even a single line of code log is enough to unveil the complexity of writing good code and easily maintainable software. It shows how easy it is to add burden to the maintenance. Luckily you can overcome this problem by following the most basic good practices of software coding. When confronted with the need to write even a log message, stick to the #1 rule of software development: keep it simple.