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:
- Logging is good for developers, not for the user .
- You should not re-invent logging framework – just use one that exists in your programming language.
- The logging should not affect the usual behavior of the program.
- You should log everywhere there is a layer made by you (including GUI).
- 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).
- The logging should be easy to configure ( where to log, what to log ).
- 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 .