search

dart-lang / lints

Official Dart lint rules; the core and recommended set of lints suggested by the Dart team.
https://pub.dev/packages/lints
BSD 3-Clause "New" or "Revised" License
118 stars 30 forks source link

core/recommended lints to support wildcard variables #204

Open pq opened 2 months ago

pq commented 2 months ago

Hey all.

As we wrap up analyzer support for wildcards, we've got some open questions about how we want the linter to behave to support (and nudge folks towards idiomatic use of) wildcards. What opinions would you all like to see enforced in the core or recommended sets?

Feel free to chime in here or https://github.com/dart-lang/sdk/issues/56595

Thanks!

devoncarew commented 2 months ago

At least historically, these two lint sets tend to trail best practices. I.e., we've used a published recommendation in effective dart as a reason to add a lint to these two sets.

Though for some items we've adjusted the lint set to prep best practices for upcoming language changes (i.e., https://github.com/dart-lang/sdk/issues/51221).

lrhn commented 2 months ago

Post feature, I'll want a "no local _ variables" as a core lint.

The only places where _ names make sense are parameters (which you need to have for the signature, but don't need to reference the value of) and destructuring/pattern matching, and pattern matching has internalized _ already.

If you write var _ = 42;, you're missing some point somewhere. It's likely a mistake. That's enough for me to want a core lint to prevent it. (If you write int _(int x) { return x; }, you're seriously missing something.

I don't know how I feel about avoid_renaming_method_parameters wrt. _. I'd personally be fine with using _ in an override, but I can see why someone using that lint may disagree. I'd definitely be fine with an override using a real name where the superinterface used _. It's not a renaming when it started from nothing. It's just a naming.

Pre-feature, guiding people away from using _ as a variable name and referencing it is a good idea. I'd just enable that as a language warning, no lint needed. We're going to change the language in a way that will make that code stop working. That's basically a deprecation warning.

pq commented 2 months ago

Thanks!

I don't know how I feel about avoid_renaming_method_parameters wrt. . I'd personally be fine with using in an override, but I can see why someone using that lint may disagree.

This is in fact how it's currently implemented. And as of https://github.com/dart-lang/sdk/commit/4a7db83dc07dff490766e8bae113fdeb5c1cfac5,

I'd definitely be fine with an override using a real name where the superinterface used _. It's not a renaming when it started from nothing. It's just a naming.

this too.