As an alternative approach, I created IOChannel (part of PawLIB, our C++ utility library). It combines logging and console output into one cohesive system...
You can set categories (error, warning, debug), and toggle or route messages based on those categories.
You can set priorities ("verbosity") on messages, for one-liner, or even real-time, control of what actually gets output. This also lets you control what priority gets sent where.
One message can go to multiple output sources, and console output can be easily toggled.
"Ignored" messages aren't even parsed, so the performance impact of leaving them in is negligible.
IOChannel uses CPGF signals/callbacks (good performance) for routing messages to any custom function, so it can be combined with any other logging, user interface, or console library or tool.
My logic behind this was that sometimes you need to write particularly complicated "print statements" that will be needed for debugging more than once. This allows those messages to stay in, and actually be useful.
Of course, what messages should even live in the code is really case-by-case, especially considering everything you've already pointed out. Just because IOChannel allows debugging messages to live permanently in the code base doesn't mean it's a free-for-all. ;)
P.S. The PII situation gives me an idea for a later version: the ability for the user to specify "message hook functions" that messages pass through either before or after parsing. Because all messages would be forced through the message hook, it would be simple to scrub all messages in one step. (Remember, you can also toggle all messages off in production, without losing them in development.)
For further actions, you may consider blocking this person and/or reporting abuse
We're a place where coders share, stay up-to-date and grow their careers.
I agree with a lot of this.
As an alternative approach, I created IOChannel (part of PawLIB, our C++ utility library). It combines logging and console output into one cohesive system...
You can set categories (error, warning, debug), and toggle or route messages based on those categories.
You can set priorities ("verbosity") on messages, for one-liner, or even real-time, control of what actually gets output. This also lets you control what priority gets sent where.
One message can go to multiple output sources, and console output can be easily toggled.
"Ignored" messages aren't even parsed, so the performance impact of leaving them in is negligible.
IOChannel uses CPGF signals/callbacks (good performance) for routing messages to any custom function, so it can be combined with any other logging, user interface, or console library or tool.
My logic behind this was that sometimes you need to write particularly complicated "print statements" that will be needed for debugging more than once. This allows those messages to stay in, and actually be useful.
Of course, what messages should even live in the code is really case-by-case, especially considering everything you've already pointed out. Just because IOChannel allows debugging messages to live permanently in the code base doesn't mean it's a free-for-all. ;)
P.S. The PII situation gives me an idea for a later version: the ability for the user to specify "message hook functions" that messages pass through either before or after parsing. Because all messages would be forced through the message hook, it would be simple to scrub all messages in one step. (Remember, you can also toggle all messages off in production, without losing them in development.)