The purpose of log files is to guide the none-developer IT service team and testers to what the program is doing so they don't need to contact you to fix the issue. Even when you have long gone and the company lost the source code, the log files should be easy enough to read so an analyst can reconstruct the program.
This is quite contradictory advice. If log files are meant to help non-developers offer program support, logs should not be so verbose that people use it to reconstruct the whole program.
For people on the support desk, logs should be as focused as possible to help aid a quick response. They have no need for thousands of lines, each describing what action a program took.
And for reverse-engineering a program, wouldn't it make more sense to interact with the actual program itself? That would be an easier and quicker way than reading the log files for all kinds of situations.
What's the fun in here? I don't get it. :)
Or is it incomplete, because the second switch statement only has an opening brace.
This is quite contradictory advice. If log files are meant to help non-developers offer program support, logs should not be so verbose that people use it to reconstruct the whole program.
For people on the support desk, logs should be as focused as possible to help aid a quick response. They have no need for thousands of lines, each describing what action a program took.
And for reverse-engineering a program, wouldn't it make more sense to interact with the actual program itself? That would be an easier and quicker way than reading the log files for all kinds of situations.