-
Notifications
You must be signed in to change notification settings - Fork 14
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
Ban use of print macros in non-test code #749
Conversation
This is what the rust big-brains came up with? |
No, I was just looking at what |
Worth asking the council of elders? The |
Given #774 (comment) should we consider other approaches? |
With f472bce (Ignore EPIPE in CLI (#746), 2024-07-17) we added the `_nopipe` variants of the `(e)print(ln)!` macros to avoid panicking when piping to head(1). However, we do not systematically enforce their use, which will inevitably lead inconsistent usage within the project. Add `clippy` lints to ban use of the print macros in all non-test code. Either the `_nopipe` variants should be used when we don't care if the input is read, or `write!` when the information is crucial, such as an interactive session.
I brought this to the council of big brains going on vacation. There are a few possibilities, but given our need to support Windows I think the approach in this PR is best.
|
eec4989
to
47e6a98
Compare
Sounds like options 3 is the best option; and let's stay vigilant in code review given the clippy limitations. |
With #746 we added the
_nopipe
variants of the(e)print(ln)!
macros to avoid panicking when piping to head(1). However, we do not systematically enforce their use, which will inevitably lead inconsistent usage within the project.Add
clippy
lints to ban use of the print macros in all non-test code. Either the_nopipe
variants should be used when we don't care if the input is read, orwrite!
when the information is crucial, such as an interactive session.