Re: The usefulness of application logging
apm35@student.open.ac.uk wrote:
I use logging as a diagnostic trace aid during development. But I leave
the logging code in when I deploy to production. I have come across
another way or working. This other way is to not bother logging
anything until there is a problem, then add logging to shed light on
the cause. The logging calls are removed once the problem has been
found and fixed. The reason given for this way of working is that
logging adds clutter to the code and it is not necessary when the code
contains no bugs. The reason I work the way I do is that the
programmers that come after me may not know that I always develop
bug-free code <grin> so they may need light shed when investigating any
issues where my code gets called. Also when logging is done by most
modules it helps to show the overall flow of control and intermediate
calculation results.
I wonder what use people make of logging generally. Perhaps people can
share their experiences and opinions here. Surely there is more than
just these two ways of doing it.
This following is not meant to be a criticism of anyone, but I have
found that inexperienced programmers are usually the ones whose code
makes heavy or systemic use of application logging as a QA technique.
Inexperienced programmers in particular often want to "see what the
program is doing" and thereby be able to reassure themselves that the
program is working as intended. And while application logging can be
used to verify a program's correct operation - more experienced
programmers know that application logging is almost always too
haphazard, error-prone and labor-intensive a techinque to be worth the
effort. Instead, experienced developers generally employ a much more
efficient method of ensuring program correctness; and for that reason
the code of experienced programmers usually contains relatively little
in the way of logging the program's execution.
There are two principal shortcomings with application logging as a QA
technique: first, adding just the "right" amount of logging to a
program is often quite difficult. Log too thoroughly and the volume of
output quickly becomes too voluminous to examine in any detail - but
log too sparingly and problems in the program's execution may not be
captured. Second, interpreting the output can be a tedious and
error-prone task and - worse - is a task that depends upon knowledge
not present in the code but known only to a particular programmer. In
fact the XP school of programming even has a name for this approach:
the "guru checks output" anti-pattern.
To find a better QA technique than application logging for ensuring a
program's correctness, it is first helpful to take a step back and
consider the "bigger picture". There are, in general, two ways to
determine whether a program is correct - the first, and for which
application logging is an example - is to verify that everything that
the program does is correct - which necessarily entails finding out
everything that the program is doing. The other way is to approach the
problem is from the other direction - that is, to make sure that the
program - whatever it is doing - is not doing anything wrong. After
all, a program that does nothing wrong has to be a correct program.
Concentrating on detecting errors turns out to have several advantages
as a QA technique over an approach that tries to detect correctness.
First, the programmer can automate the error detection by placing
asserts in the code. A failed assertion indicates a programming error.
Asserts do more than merely detect errors, they also preempt errors by
formalizing and regularizing the program's implicit operating
assumptions, particularly at the interface layer between a function and
its caller. And unlike application logging, there is little penalty for
making heavy use of asserts. And I would go so far as to say that there
are probably very few - if any - situations in which application
logging could not be more effectively and efficiently replaced with one
or more asserts.
I would point out that there are a few instances in which application
logging is useful: in particular, test code often logs a program's
state or output in order to compare against the expected state or
output. Note that logging in this situation is being used in an
automated context - and is really more akin to an assert than it is a
general execution log. So as a rule of thumb, I would state that any
type of application logging in which the expected output is either not
tested programatically for correctness - is probably not a worthwhile
QA technique.
Greg
[ See http://www.gotw.ca/resources/clcm.htm for info about ]
[ comp.lang.c++.moderated. First time posters: Do this! ]