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 ¹: Corollary : Every software needs logging and this should be performed as good as possible,with all specific details to understand the problem.

Note ² : 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 ³ :  For example logging a function that modifies some parameters or logging variable.ToString() and this throws the infamous “null reference”

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

Note ⁵ : 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 ⁶:  This means it is easy for DevOps to configure the software to not log into production the debug levels .

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