Closed a14n closed 1 year ago
I'd be inclined to deprecate.
It's noteworthy that prefer_constructors_over_static_methods
is not included in any of the rulesets we're trying to align (https://github.com/dart-lang/linter/issues/1365#issuecomment-454416014) so this one in particular would I think effect no-one.
@a14n, @kwalrath: are you aware of any others?
I disagree. The purpose of the linter is not to enforce the style guide. The purpose of the linter is to enable users to customize the set of diagnostics that are produced by the analyzer.
If we have evidence that there are no users that are enabling this lint, then I think it's reasonable to remove it. But we should not remove it just because it's no longer mentioned in the style guide. It's OK for users to choose to follow additional guidelines that are not in the style guide. At the risk of being heretical, it's even OK for users to choose to not follow guidelines that are in the style guide.
I disagree. The purpose of the linter is not to enforce the style guide. The purpose of the linter is to enable users to customize the set of diagnostics that are produced by the analyzer.
If we have evidence that there are no users that are enabling this lint, then I think it's reasonable to remove it. But we should not remove it just because it's no longer mentioned in the style guide. It's OK for users to choose to follow additional guidelines that are not in the style guide. At the risk of being heretical, it's even OK for users to choose to not follow guidelines that are in the style guide.
Agreed. But we should certainly remove lints that are irrelevant or problematic in Dart 2. Some used to be in the style guide but were removed (see dart-lang/site-www#863, dart-lang/site-www#889, and other changes to Effective Dart). Here are some possibilities:
always_declare_return_types
avoid_types_on_closure_parameters
type_annotate_public_apis
super_goes_last
: Irrelevant because Dart 2 enforces this. (I can't find this in the SDK changelog, but it's mentioned in dart-lang/site-www#863.)prefer_constructors_over_static_methods
: Irrelevant from the POV of reading code (though not from the implementer's or doc reader's POV).Also, it's hard to tell the difference between these two lints, but maybe that's just a matter for the help text:
package_api_docs
public_member_api_docs
I disagree. The purpose of the linter is not to enforce the style guide. The purpose of the linter is to enable users to customize the set of diagnostics that are produced by the analyzer.
💎
I completely agree.
My thinking was that in this case in particular the advice may have gone stale in the presence of optional new
and const
. Which is just to say @kwalrath is totally on to something:
But we should certainly remove lints that are irrelevant or problematic in Dart 2.
Emphatic +1.
I'm surprised this isn't being tracked already since we've chatted about it a bunch. Anyway, I opened https://github.com/dart-lang/linter/issues/1372 to track. @kwalrath: thanks so much for seeding the list!
it's hard to tell the difference between these two lints ...
Opened #1373. Thanks!
I think this has been resolved then. We can keep rules even if their backlink to Effective Dart disappears.
For instance
prefer_constructors_over_static_methods
was created to enforce a lint that has disappeared: