It's an all-time favorite topic for me, finally writing down this article.
Check if your software has poor logs, Below is symptoms of poor logging
- Developer asks to reproduce the issue
- How many bugs closed due to root cause not found
- Can you find the issue without attaching a debugger
- How quickly you can create the scenario from logs
- Can you identify faulty threads and function
- a lot more
- Remote monitoring, Find a fault without visiting site
- Preemptive customer support
- For an example "Ink will vanish in 5 days"
- Find most of used and unused features of your product
- Find user behavior for your product
- Calculate statistics like memory usages, number of time system/software restarted
- Has time stamp , File name, Line number, and Thread number and process info
- Capture all user interactions, example
- “User A clicked “Ok” button
- “User B Clicked “Play Button”
- If programming in object-oriented language, why not logs in real word language, Stop using cryptic language, Yes grammar and spelling matters
- “User requested stop by pressing stop button”
- “Could not complete user request”
- Don’t get carried away by .Net, File name and line number in logs are life-saving
- if(do this())else { /*log could not do this */ }
- Functions entry and exit shall be marked with timestamp
- Convert Enumeration in string before logging
- Logs unexpected value
- “An error encountered while processing user requested, Expected value is 20 actual value is 40”
- Save your stack on unhandled exceptions
- Don’t spoil logging with extra and repetitive information
