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

Update dartanalyzer lint rule defaults to an empty set #57880

Closed
pq opened this issue Jan 19, 2019 · 9 comments
Closed

Update dartanalyzer lint rule defaults to an empty set #57880

pq opened this issue Jan 19, 2019 · 9 comments
Assignees
Labels
analyzer-linter Issues with the analyzer's support for the linter package area-analyzer Use area-analyzer for Dart analyzer issues, including the analysis server and code completion. type-enhancement A request for a change that isn't a bug

Comments

@pq
Copy link
Member

pq commented Jan 19, 2019

Part of #57873: update the lint registry defaults to line up with those defined by package:pedantic.

EDIT: as per conversation below, the new plan is to have no rules default to on.

@pq pq added the type-enhancement A request for a change that isn't a bug label Jan 19, 2019
@pq pq self-assigned this Jan 19, 2019
@bwilkerson
Copy link
Member

As I said elsewhere, I would prefer to see us remove the notion of "default" rules entirely. As far as I can tell, these defaults do not impact either the command-line analyzer or the analysis server. I'm not sure whether they impact the linter app, but I don't see any value to having them there. Do they bring some value that I'm not seeing?

@pq
Copy link
Member Author

pq commented Jan 19, 2019

As far as I can tell, these defaults do not impact either the command-line analyzer

If you run dartanalyzer --lints and there is no .analysis_options.yaml, the defaults are what you get.

// If lints turned on but none specified, then enable default lints
if (options.lint && options.lintRules.isEmpty) {
options.lintRules = Registry.ruleRegistry.defaultRules;
verbose('Using default lint rules');
}

Initially the idea of a default set of rules was introduced to make trying out linting easier. (At that point no one had any experience w/ analysis_options, and technically may have predated them!) I think if the defaults are actually representative of some standard they may continue to add value but as they are today they are a distraction at best. An alternative would be to remove the default set entirely and I'm actually OK with that though I guess, technically, it'd be a breaking change?

@bwilkerson
Copy link
Member

An alternative would be to remove the default set entirely and I'm actually OK with that though I guess, technically, it'd be a breaking change?

That's my preference. I don't know whether it would be a breaking change from a practical perspective. It would be nice to have analytics to tell us whether anyone runs the command-line analyzer with --lints. I suspect that the answer is 'no', but I have no proof.

On the other hand, changing the set of rules that we're running when someone does that is technically a breaking change whether we change it to a different non-empty set (such as pedantic) or to an empty set. So if we're going to make a breaking change, let's just remove the functionality.

@pq
Copy link
Member Author

pq commented Jan 19, 2019

On the other hand, changing the set of rules that we're running when someone does that is technically a breaking change whether we change it to a different non-empty set (such as pedantic) or to an empty set.

Oh, I knew you'd say that. 😄

I guess I can go either way. I'd be curious what other folks think and happy to go with the flow. As long as we change the current set of defaults to something sensible (empty or pedantic), I'm good!

/cc @devoncarew @stereotype441

@devoncarew
Copy link
Member

Being more restrictive would likely be a larger change from the POV of users than being less restrictive?

I'm not sure what lints we have enabled by default, but dropping down to an empty set of lints enabled if nothing is specified makes sense to me. People can then opt-into the lints they want, either deliberately by adjusting their analysis options, or through pedantic if they create a new project w/ stagehand.

@devoncarew
Copy link
Member

I poked around the source a bit but couldn't see how or where the current default lints are defined.

@bwilkerson
Copy link
Member

By using registerDefault when registering a lint, as here: https://github.com/dart-lang/linter/blob/master/lib/src/rules.dart#L182.

We might also want to make the --lints option print a message explaining how to upgrade if there are no lints defined because that would be an indication that someone was relying on the defaults.

@devoncarew
Copy link
Member

Ah, thanks!

For posterity, here are the current lints enabled by default:

CamelCaseTypes
ConstantIdentifierNames
EmptyConstructorBodies
LibraryNames
LibraryPrefixes
NonConstantIdentifierNames
OneMemberAbstracts
SlashForDocComments
SuperGoesLast
TypeInitFormals
UnnecessaryBraceInStringInterps
UnnecessaryNullAwareAssignments
UnnecessaryNullInIfNullOperators

@pq pq changed the title Update dartanalyzer lint rule defaults to use pedantic Update dartanalyzer lint rule defaults to an empty set Jan 19, 2019
@pq
Copy link
Member Author

pq commented Jan 19, 2019

SGTM.

I've update the title to reflect the new plan.

Thanks for the thoughtful conversation!

@devoncarew devoncarew added analyzer-linter Issues with the analyzer's support for the linter package area-analyzer Use area-analyzer for Dart analyzer issues, including the analysis server and code completion. labels Nov 18, 2024
@devoncarew devoncarew transferred this issue from dart-lang/linter Nov 18, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
analyzer-linter Issues with the analyzer's support for the linter package area-analyzer Use area-analyzer for Dart analyzer issues, including the analysis server and code completion. type-enhancement A request for a change that isn't a bug
Projects
None yet
Development

No branches or pull requests

3 participants