Here are the best practices and how binary logger relates to them:
- Use clear key-value pairs. This is also called structured logging and is one of the techniques recommended to try by the latest ThoughtWorks technology radar. With binary logger this is possible without ANY additional load on the embedded device (not ROM, not RAM, not CPU, not bandwidth).
- Create events that humans can read. Obviously, binary logger can't offer this. You need a script (provided with the library) and the originally source code to decipher the binary log stream. On the other hand you can be really verbose in the decrypted log and strive for maximum readability without any load on the embedded device.
- Use timestamps for every event. Do it! It doesn't cost you much with binary logger.
- Use unique identifiers (IDs). See last point.
- Log in text format. Again, this is where binary logger has its weakness.
- Use developer-friendly formats. See first point: you are rather free in the format because it doesn't cost you any load on the embedded device.
- Log more than just debugging events. Because logging with binary logger is very cheap on resources like stack, you might add logging messages where you couldn't with a standard logging facility.
- Use categories. Adding categories to log messages costs you nothing on the embedded device with binary logger if you add them as static text.
- Identify the source. The binary log stream format automatically contains the source of any log event, because it's needed for deciphering the binary log stream.
- Keep multi-line events to a minimum. Do as you like with binary logger.
I think the above best practices are really good advice. Binary logger might help you to follow them when the constraints of your embedded device would normally let you refrain from it. I'd love your feedback on this post and binary logger!