mercoledì 15 settembre 2010

Log log log and always log !

No maters which tool you use, but you MUST log !

If you develop an application of more then 3 lines of code (and do not participate to a Java Compact Code Competition), at least one every 5 should be a log line.

The worst parts of programming are documenting and then logging, specially because most time we add add and add logging during the troubleshooting of bugs, but then we never rationalize them and so thousands of useless logs are generated and the really useful few ones got lost in an ocean of noise.

The core of a good logging is the choose of the right detail and information you put into the messages, and of a tool that enable you to easily  activate and set the needed level at runtime with out overloading too much the execution of the application.

As almost all the technical works you must find the right equilibrium between too much and too few, and you can only use your thumb as a meter.

But you MUST always keep in your mind the good old rule:
IF YOU DO NOT LOG YOU’LL NEVER KNOW WHAT YOU ARE DOING WRONG !

2 commenti:

  1. By the way:

    Brian W. Kernighan and Rob Pike in "The Practice of Programming":

    "As personal choice, we tend not to use debuggers beyond getting a stack trace or the value of a variable or two. One reason is that it is easy to get lost in details of complicated data structures and control flow; we find stepping through a program less productive than thinking harder and adding output statements and self-checking code at critical places. Clicking over statements takes longer than scanning the output of judiciously-placed displays. It takes less time to decide where to put print statements than to single-step to the critical section of code, even assuming we know where that is. More important, debugging statements stay with the program; debugging sessions are transient."

    I too prefer log to debug... the problem is to make "judiciously-placed displays" !

    and of course read : http://logging.apache.org/log4j/1.2/manual.html

    RispondiElimina
  2. Just a quick format reference:

    Conversion Character Effect
    c - category of the logging event
    C - fully qualified class name of the caller issuing the logging request
    d - date of the logging event.
    The date conversion specifier may be followed by a date format, for example, %d{HH:mm:ss,SSS} or %d{dd MMM yyyy HH:mm:ss,SSS}
    F - file name where the logging request was issued.
    l - location information of the caller
    The location information can be very useful. However, its generation is extremely slow and should be avoided.
    L - line number from where the logging request was issued.
    Caller location information is extremely slow and should be avoided.
    m - application supplied message associated with the logging event.
    M - method name where the logging request was issued.
    n - platform dependent line separator character or characters.
    p - priority of the logging event.
    r - number of milliseconds elapsed from the construction of the layout until the creation of the logging event.
    t - name of the thread that generated the logging event.
    x - NDC (nested diagnostic context)
    X - MDC (mapped diagnostic context) - must be followed by the key for the map placed between braces, as in %X{clientNumber}
    % - The sequence %% outputs a single percent sign.

    RispondiElimina