mirror of
https://github.com/ramsayleung/rspotify.git
synced 2026-04-26 07:55:55 +03:00
[GH-ISSUE #204] Extreme clippy linting #67
Labels
No labels
Stale
bug
discussion
enhancement
good first issue
good first issue
help wanted
pull-request
question
No milestone
No project
No assignees
1 participant
Notifications
Due date
No due date set.
Dependencies
No dependencies set.
Reference
starred/rspotify#67
Loading…
Add table
Add a link
Reference in a new issue
No description provided.
Delete branch "%!s()"
Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?
Originally created by @marioortizmanero on GitHub (Apr 20, 2021).
Original GitHub issue: https://github.com/ramsayleung/rspotify/issues/204
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:
orpatterns inmatchexpressions.100_u8might look more readable than100u8, butrspotify::clientand then access its items withclient::, but that would be repetitive in cases likeClientErrororClientResult, 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.asconversions 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_000is 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.
@marioortizmanero commented on GitHub (Apr 20, 2021):
My own opinion:
ClientErrorandClientResult, I've never been fond of theClientprefix in these cases, because we don't have another "global" error type anyway. But I would leave the models alone, let's just keep them as close as possible to the Spotify API.IdError, but not really sure.@flip1995 commented on GitHub (Oct 5, 2021):
Hey, Clippy maintainer here. You shouldn't enable the
restrictiongroup as a whole. Clippy will even emit a warning if you do so. This is because lints in this group are allowed to contradict other lints in Clippy and the Clippy output is then just a unfixable mess.nurseryis for buggy/unfinished lints, so expect much noise from this group. I wouldn't recommend to enable this group, but if you want to help us test those lints, we wouldn't hold you back :).pedanticis pedantic and you should expect manyallows popping up in the code. Clippy uses the wholepedanticgroup to lint itself, so using it here should be fine, if you want Clippy toannoyhelp you with everything.@marioortizmanero commented on GitHub (Dec 29, 2022):
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.
@flip1995 commented on GitHub (Dec 30, 2022):
If you want to do a release, then you should consider setting the
avoid-breaking-exported-apitofalse, which will enable additional behavior for some lints. You can do so by adding aclippy.tomlfile and putthere.
You shouldn't keep this enabled in CI/after v1.0.
@github-actions[bot] commented on GitHub (Jul 4, 2023):
Message to comment on stale issues. If none provided, will not mark issues stale