New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
cmd/vet: printf: enforce 'f' suffix convention for printf wrappers, and only them #27036
Comments
Putting as release blocker for now. Please change if you don't believe it's a problem for 1.11 final and can be done in a point release. /cc @rsc |
Never mind. Not a release blocker. |
I'm not sure if this would qualify for vet's frequency or precision criteria. Do you have any numbers to support that this is a common occurrence? I do see typos when people use As for precision - I think it would be fairly easy for this check to run into false positives. For example:
I don't think the code above is wrong, and I don't think naming it |
Another thought about false positives - perhaps they would go away if this check only ran if the string parameter was named |
Your LogRequest example is not a printf-wrapper, strictly defined, because it doesn't forward the last two parameters. (You need the ... to properly forward the call.) I think the false positive rate will be close to zero. |
Ah - I misunderstood the idea, then. I agree that there shouldn't be any false positives, but I'm still unsure if this happens often enough. |
I don't think vet is for enforcing naming conventions. |
Rereading, I think both the examples are clearly fine as is. |
Vet could flag as problematic any function whose name ends in "f" and whose parameter types end with (string, ...interface{}) but that does not forward the last two parameters to a printf wrapper.
(False positives are possible for packages that implement fmt-style formatting without using fmt, such as mpvl's localized text support. A workaround would be for such functions to contain a dummy unreachable forwarding call to fmt so that vet treats them as printf wrappers.)
Conversely, if a function has that signature and does forward to a printf wrapper, the function name should end in "f".
The text was updated successfully, but these errors were encountered: