The 10 commandments for writing good logs

Given how easy is to log your application flow these days, it comes as no surprise that many developers abuse and misuse them. There are many anti-patterns that can be applied to logging and this article tries to help you avoid some of them.

Here’s my list of 10 commandments for logging:

1. Don’t be fancy: avoid formatting the messages and/or adding special characters not related to the event being logged.
   • This is bad: “****** The application has started ********”
   • This is good: “The application has started”
2. Be clear: write short statements that go straight to the point. Avoid directly referencing symbols of your code.
   • This is bad: “userId=orpiske.net, loginStatus=successful”
   • This is good: “User ‘orpiske.net’ successfully logged in”
3. Check the spelling and grammar of your log messages. Log messages with errors sound unprofessional. Include that in the checklist for the peer review sessions.
4. Use the correct message level. If you don’t use them accordingly, there’s a high risk of your support team ignoring them. Eventually, they will miss a message that’s indeed FATAL or that’s indeed a WARNING that something wrong is going on.
5. Don't log too much:
   • It creates a lot of noise for high volume applications
   • It increases the I/O and may decrease the performance of your application.
6. Do not forget: the right tool for inspecting your code is called “debugger”.
7. Avoid logging messages into a database: it is a waste of valuable resources, makes it too complicated to maintain and decrease the performance.
   • If you must log to the database (e.g.: to comply to regulations, legacy designs, etc) then abstract it.
8. Different transaction types should have different logs. Please note the distinction between transaction types and transaction flows.
9. Logs used to comply with local regulations should be separate from log messages used to trace the transaction flow.
10. Have a style and standard. Document it.