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

require qualification #36

Open
blueforesticarus opened this issue Mar 30, 2023 · 0 comments
Open

require qualification #36

blueforesticarus opened this issue Mar 30, 2023 · 0 comments
Labels
A-user-story Area: A user story or a related issue

Comments

@blueforesticarus
Copy link

Lint explanation

This would be a configurable lint, which allows certain crates/crate items to be used qualified.
It is motivated by the fact that using unqualified items with common names can be confusing, and lead to stylistic inconsistency.

More generally it is motivated by the fact that unqualified names are often easier to write out when first developing a file, but qualified names generally are more readable. This creates a common refactor path where you write your code (often using unqualified names and using the editor / rust-analyzers quickfix import); later replacing many unqualified names with qualified ones to make it clearer what things are. This lint would allow automating/enforcing some of this kind of refactoring.

Example code

In my code, I try to always use tracing calls fully qualified, ie tracing::info!(...); instead of info!(...);
This has 2 nice properties:

  1. It is immediately obvious that what I am calling is in fact tracing (and not some accidentally imported info from log or slog or etc.)
  2. I can find all logs in my program by searching for tracing.

What I propose is that if tracing::info is in the configured list of items requiring qualification, then a warning would be emitted, with a suggested fix adding the qualification as above.

Notes

One extra consideration is how many levels of qualification.. In my case I actually use tracing reexported under another crate as boilerplate::crates::tracing. In this case the desired fix is to use boilerplate::crates::tracing, and qualify with tracing::info!(...);. However someone might want instead to require a full qualification of boilerplate::crates::tracing::info!().

Another lint someone may want is to forbid qualification of certain items. For example, in a workspace I may prefer to forbid qualification of some_workspace_member::thing::Thing and instead require thing or Thing be imported with use.

Another, more drastic idea

Going even further. I've often wanted to use this pattern for my imports:

mod very_complex_crate {
     pub use very_complex_crate {
         thing1,
         deeply::nested::{
             thing2,
             thing3::Thing3,
         }
     }
}

which has the benefit of making it very obvious everywhere that any very_complex_crate items are being used (could be very good for readability, perhaps changing the mod name to reduce confusion, anyway somewhat besides the point here). I ended up not using this convention because it did not play well with lints and code-suggestions. If there was some way I could implement a lint with suggestions to enforce this pattern for complex certain crates, then a single cargo fix would dramatically improve the readability of more than one of my code bases.

@blueforesticarus blueforesticarus added the A-user-story Area: A user story or a related issue label Mar 30, 2023
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
A-user-story Area: A user story or a related issue
Projects
None yet
Development

No branches or pull requests

1 participant