$ \def\Vec#1{\mathbf{#1}} \def\vt#1{\Vec{v}_{#1}(t)} \def\v#1{\Vec{v}_{#1}} \def\vx#1{\Vec{x}_{#1}} \def\av{\bar{\Vec{v}}} \def\vdel{\Vec{\Delta}} $

Harald Kirsch

about this blog
2024-02-12

Good Log Messages

In my previous jobs I also had to analyse log messages for which I did not have the code readily available. Besides intentionally idiotic messages like "trouble in paradise", I had my fair share of message that made me grind my teeth. They read like:

These were the full texts, seriously. Why does the idiot not list the file it can't open? Why can't they just tell me which crap they can't parse? Had the information been in the log message, often-times the support case wouldn't even have reached my inbox. The customer could have fixed it in a minute by providing the file missing or fixing the string to be parsed.

To avoid the above I came up with rules for what a good logging message should tell us. This applies to warnings and errors, not so much for purely informational message.

Log messages are also customer communication. So as a fourth rule: avoid developer vocabulary. Though I came across only one example. In Java land we might talk about "resource", whatever it is. Other people know this rather as file or something.