-
Notifications
You must be signed in to change notification settings - Fork 124
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
Extreme clippy linting #204
Comments
My own opinion:
|
Hey, Clippy maintainer here. You shouldn't enable the
|
We should do one last run before releasing v1.0. @ramsayleung, I've added a milestone that includes the most important issues we need to address before releasing the first stable version. I haven't included stuff like #377 because these aren't breaking changes and can be implemented later on just fine. I'm mainly talking about issues that may involve re-designing parts of the library, so that we avoid such large breaking changes early on. |
If you want to do a release, then you should consider setting the avoid_breaking_exported_api: false there. You shouldn't keep this enabled in CI/after v1.0. |
Message to comment on stale issues. If none provided, will not mark issues stale |
Is your feature request related to a problem? Please describe.
I just learned about the more "extreme" clippy lints, which can be enabled by adding this to the header of
lib.rs
:They are "extreme" for a reason; it might not be a good idea to have them always enabled because they can be annoying/wrong, but I think it's a good idea to try it out from time to time and consider its suggestions in a discussion like this. Here's a summary of the lints it found:
or
patterns inmatch
expressions.100_u8
might look more readable than100u8
, butrspotify::client
and then access its items withclient::
, but that would be repetitive in cases likeClientError
orClientResult
, which would look likeclient::ClientError
.This also includes cases like
album::SimplifiedAlbum
, which are more complicated because we try to follow the same Spotify names.!
might make code more readable.as
conversions that might lose data. Note that most of them aren't rally necessary, including the unsafe transformation forId
, about which there's not much else to do._
digit separators;1_000_000
is more readable than1000000
.You can find examples of the lints I mentioned by searching in the following log:
Full output for `default` branch
What do you think? None of these are really important, so no rush.
The text was updated successfully, but these errors were encountered: