Skip to content
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

Apply clippy::use_self #14798

Closed
wants to merge 1 commit into from
Closed

Apply clippy::use_self #14798

wants to merge 1 commit into from

Conversation

EdJoPaTo
Copy link
Contributor

@EdJoPaTo EdJoPaTo commented Aug 17, 2024

Objective

When looking through the changes #14782 would produce I noticed another lint (clippy::use_self) that should be quite neat here (and solves some of unused_qualifications cases already which is why I don't want to supply a PR for both at the same time.)

In a bunch of cases Self is already used near the suggestion to use Self of use_self. So I assume this is accepted code which this lint enforces further in the future.

Solution

Add clippy::use_self (and alphabetically sort its lints) and mostly --fix its way through the code. cargo fmt results in less lines for the same code afterwards. Also removed some empty lines here and there.

I also manually fixed the false-negative rust-lang/rust-clippy#12381 in the cases I noticed.

--fix didn't work in bevy_ecs which turned out to be a clippy false-positive: rust-lang/rust-clippy#13277

Testing

cargo clippy still seems to be happy. cargo run -p ci seems to work too. (It produces some errors of this kind, but it doesn't seem relevant for this PR: Could not set global logger and tracing subscriber as they are already set. Consider disabling LogPlugin.)

Reviewing this is probably quite messy as this changes hundreds of files. This will likely also produce many merge conflicts. I am happy to integrate other merged branches for some time if interest in merging this is there. But similar to #10749 it shouldn't stay open for too long due to its amount of affected files.

Copy link
Member

@janhohenheim janhohenheim left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Way nicer for refactoring names. There are some cases where I wouldn't use Self, but the pros outweigh the cons imo

@janhohenheim janhohenheim added C-Code-Quality A section of code that is hard to understand or change S-Needs-Review Needs reviewer attention (from anyone!) to move forward labels Aug 17, 2024
@BD103 BD103 added the A-Cross-Cutting Impacts the entire engine label Aug 18, 2024
@BD103
Copy link
Member

BD103 commented Aug 18, 2024

I'm in favor of this for its consistency, but I haven't looked through each file yet.

@EdJoPaTo
Copy link
Contributor Author

Way nicer for refactoring names.

Personally I think it's not only nicer for refactoring. It's also quite nice when reading code as its instantly clear something is exactly the given type. fn some_magic(&self, whatever: &Self) is easy to read even when the impl Whatever is further away or multiple quite similar structs like Line and Lines exist. So to me, it also reduces confusion when reading code.

@BD103 BD103 added the D-Straightforward Simple bug fixes and API improvements, docs, test and examples label Aug 19, 2024
@alice-i-cecile alice-i-cecile added X-Contentious There are nontrivial implications that should be thought through X-Controversial There is active debate or serious implications around merging this PR and removed X-Contentious There are nontrivial implications that should be thought through labels Aug 19, 2024
@alice-i-cecile
Copy link
Member

I don't think we should do this. This is a noisy change, and more importantly, I prefer the other style. When reviewing / reading code snippets, it's much harder to constantly keep track of what scope we're in, rather than just using the names. This has been attempted before in #4152 and was rejected by maintainers there. Closing this out as well, sorry.

@EdJoPaTo EdJoPaTo deleted the use_self branch August 19, 2024 16:48
@EdJoPaTo
Copy link
Contributor Author

EdJoPaTo commented Aug 19, 2024

When going through the changes I noticed a bunch of places where this is already used. Maybe they should be changed then?

$ rg --no-heading Self | wc -l
7181

This PR was about ~1600 lines touched, there are already 7k with Self. So this change is not that significant in the regard of using Self.

To quote the consensus of #4152:

I'm in favour of doing nothing at all

Guess I should have searched the existing PR about use_self better first 😇

@alice-i-cecile
Copy link
Member

Yeah, I prefer the other style, but without a lint to enforce it I don't think it's worth spending time to update the other style.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
A-Cross-Cutting Impacts the entire engine C-Code-Quality A section of code that is hard to understand or change D-Straightforward Simple bug fixes and API improvements, docs, test and examples S-Needs-Review Needs reviewer attention (from anyone!) to move forward X-Controversial There is active debate or serious implications around merging this PR
Projects
None yet
Development

Successfully merging this pull request may close these issues.

4 participants