Why not take the extra half a second to make those random strings meaningful and hidden behind a DEBUG log level?
Why not take the extra half a second to make those random strings meaningful and hidden behind a DEBUG log level?
The point that he was making with this was that over-logging is a good thing - this probably wasn't something the initial author thought was going to be terribly informative, hence the random string. And yet it ended up diagnosing a real world problem.
In a perfect world, by all means properly write out your messages - but if you're stalling on a log message because you're not sure how to phrase it, you may get concrete benefit from just dropping a FUUUCCKKKKKasdjkfnff and moving on.
When the problem occurs, it's pretty quick for the guy who needs to fix it at 2am, to find where it exploded in the code base, while the original developer is (maybe) passed out in a bar somewhere.
Not much else matters. He could of just done :( x 10 and had the same result. The main thing is, it's easily traceable!
At the time of writing the code, you're hopefully thinking through "how could this fail?"
There's your log message.
"FUUUCK" is awfully good at conveying the seriousness of the error, and "aslfkhsdf37" ensures that the string is unique, so you can pinpoint it instantly in your gigantic codebase.
The fact is, it kind of works. Something like "missing record (line 38)" doesn't indicate the severity, there might be 10 different "missing record" error strings in your codebase, and somehow in real life, line numbers and filenames never seem to quite match up like they should (transcompilation, async callbacks, and so on.)
Let he who has never written a frustrated, nonsense, print statement throw the first stone, if you will.
Plus, the statement is not only meaningful, but also very expressive.