☂️ [tracking] rename lints

[pq]

Lint Renaming for 3.0

We can expect adopters of 3.0 to tolerate some breaking changes and imagine that the upgrade will involve some code fixing up. This might be a good opportunity to tackle some lint renames (especially if dart fix can automate much or all of the migration).

Concretely, there are (at least) 2 kinds of renames to consider.

1. fixing of awkward names (e.g., unnecessary_parenthesis should really be unnecessary_parentheses), and
2. removal of "prescriptive" language from names

1. Awkwardness / Inconsistency

Some names are poorly named (unnecessary_parenthesis is just wrong -- it's not one unneeded parenthesis, it's the pair) and/or inconsistent (unnecessary_parenthesis is singular and the bulk of lints are pluralized; no_runtimeType_toString uses an odd mix of CamelCase and underscore naming while the bulk of lints are purely underscored).

Tracking issue: #3873.

2. Prescriptive Naming

A host of lints have prescriptive language in the names (e.g., prefixes like prefer and avoid). Historically, these reflected language in the style guide and seemed to make sense at the time. In retrospect this choice has some significant downsides and there have been a number of conversations about a big rename.

The current suggestion for naming is more neutral:

[Lints should be given a] short name using Dart package naming conventions. Naming is hard but strive to be concise and consistent. Prefer to use the problem as the name, as in the existing lints control_flow_in_finally and emptycatches. Do not start a lint's name with "always", "avoid", or "prefer". Where possible, use existing rules for inspiration and observe the rules of [parallel construction](https://en.wikipedia.org/wiki/Parallelism(grammar)).

(from writing-lints.md).

The goal is to update all lints to this new guidance.

Tracking issue: #3872.

[srawlins]

I think we should also rename unnecessary_parenthesis to unnecessary_parentheses. Most rules use plural text to describe a pattern that a developer should use or avoid, but this rule seems to go out of its way to call out the singular form of "parentheses."

[bwilkerson]

And the name is wrong because you can't have a single parenthesis that's unnecessary; either they're both necessary or they're both unnecessary. :-)

[parlough]

As I think more and more about documentation and discovery, I'm increasingly worried about the status of linter rule names.

Some are positive and/or instructional, well others (like diagnostics) are about the problem.

I think the benefits to standardization are pretty large.

First in terms of choosing lints, the inconsistency results in developers not being able to fully rely on just the name to understand it's goal. We have a lot of lints now, so being able to gain interest from just the name is pretty valuable.

Second, as users are programming, receiving a lint in their IDE or by dart analyze, they shouldn't have to think about lint diagnostics differently than other diagnostics. Having their names be more consistent with other diagnostics could help their understanding and workflow.

If we have a mechanism to rename that dart fix can handle and we can be aware of from the documentation for redirects, I think this would be worthwhile, especially if we can get closer to the other diagnostics.

[bwilkerson]

I agree with all of that, and I'd like to see the lint names be more consistent. From my perspective it's primarily a question of priorities; is renaming lints more important than adding more quick fixes or refactorings, etc.

[parlough]

That makes complete sense to me, just wanted to add my thoughts as I'm looking through them :)

My feeling is that fixes/refactoring/etcs are more important, and hopefully as the cadence of new lints is reduced and the backlog of diagnostics are worked through, we can slowly catch up and revisit this in future.