7 rules of logging ( and 7 notes)

Those are my 7 rules for logging (you can read also the side note for every rule)

So here they are:

  1. Logging is good for developers, not for the user .
  2. You should not re-invent logging framework – just use one that exists in your programming language.
  3. The logging should not affect the usual behavior of the program.
  4. You should log everywhere there is a layer made by you (including GUI).
  5. If the software returns/throws a generic code for error,then he should log the concrete details of what happened and the time * although this should be automatically done by the logging framework).
  6. The logging should be easy to configure ( where to log, what to log ).
  7. The format in which are you logging should be easy to understand by an automatic text parser

Note 1: Corollary : Every software needs logging and this should be performed as good as possible , with all specific details to understand the problem.

Note 2 : Choose one that works well in multi-threaded application, has multiple outputs ( database, log file, console , others) and provides various levels of logging( at least debug, info , error). For   .NET : log4net, nlog .  Do re-invent the wheel – if you believe that you can make something better .

Note 3 :  For example logging a function that modifies some parameters or logging variable.ToString() and this throws the infamous “null reference”

Note 4 : See http://liddellj.com/2014/09/09/log-all-the-things 

Note 5 : For example, if you throw a generic exception “ Something bad happened “ in order to not bother the user with mundane details, you should log the primary error and the reason that you throw the generic exception

Note 6:  This means it is easy for DevOps to configure the software to not log into production the debug levels .

Note 7: See http://dev.splunk.com/view/logging-best-practices/SP-CAAADP6