But sure, vibe away.
Yes, f""-strings may be evaluated unnecessarily (perhaps, t-strings could solve it). But in practice they are too convenient. Unless profiler says otherwise, it may be ok to use them in many circumstances.
Wait a second.. If I do ANY ACTUAL engineering and log out the time savings, it's completely negligible and just makes the code harder to read?
It is complete insanity to me that literally every piece of programming literature over the past sixty years has been drilling the concept about code readability over unncessary optimizations and yet still I constantly read completely backwards takes like this.
The footgun is there. Hot-loop debug logging can cost a ton with f-strings, and an LLM can just as easily use the standard log formatting without this problem. Few people use a profiler prior to a production bug (or just end up with eye popping autoscaling bills).
Shrug. I guess everyone can learn for themselves if it’s a problem for them. But I’ve been there; it would be nice if the tools did better with best practices.
Even better, you should be interpreting them at time of reading the log, not when writing it. Makes them a lot smaller.
This reminds me of a fun interaction in browser devtools: you can log a complex struct to the console. The browser does not copy the entire nested structure when you do so immediately, meaning that if someone mutates that struct after it was logged, the value you see depends on when you expanded the nested struct.
in C this leads to remote code execution (%n and friends)
in java (with log4j) this previously lead to remote code execution (despite being memory safe)
why am I not surprised the slop generator suggests it