> printf debugging isn't without its annoyances, namely removing the print statements once you're done.
Use something like stacked git[1], and then it's just one "stg pop" and poof, they're gone.
> Any feedback is much appreciated.
There is way too much going on in this code whose feature essentially boils down to
func Printf(f string, v ...any) {
if CONDITION {
fmt.Printf(f, v...)
}
}
Writing a stack trace is fully unrelated to Printf(), and should be separated.Very cool!
Just one thought: I don't think your stack traces need to include the lines inside Printf itself and it adds to the noise a bit. Maybe just go up to the line where the call to Printf is made?
it doesn't appear to truly be zero cost if you log variables that can't be eliminated. The only way (I believe) to implement zero cost is some type of macro system which go does not support.
Cool lib! I took the same approach for my zero cost debugging assertion Go library
In extreme processing needs, I suppose the elimination of a check that would happen with a level logger is a solid trade off.
My favored approach is a context aware level logger with structured logs going to an aggregator like Splunk.
Because it is context aware, custom filtering logic is available in a middleware.
I'm curious why you prefer this over writing tests.
How does the dead code elimination work when using args to Printf? If static strings are fed into an empty function, I can imagine it does nothing. However, this I have less of a firm grip upon
since surely golang will still call Something, and still call PrintfAnd don't misunderstand me: it's a grave pet peeve of mine to do action inside the args to Printf but I can tell you it's a very common [anti-]pattern so I'd presume your users will want a story for how that interacts with the "disappears completely" claim