Linter Configurability

[pq]

Migrated from dartbug.com/22002:

Some amount of configurability would be nice eventually. Groups of rules to include/exclude, such as excluding the PREFER/AVOID rules or equivalently only including DO/DONT rules. Alternatively each rule can have an ID (same as might be used by the output or #88), and configuration can happen at that level. The config could be specified by something like a .dartformatrc in the project root i.e. something that is shared with a team via source control. This is how jshint and jscs specify their config for example. Might be nice to integrate with .editorconfig as well (this could replace the current line length option and many others that may be requested in the future).

[pq]

Picking up on some of @alan-knight's concerns voiced around false positives for #27:

Minimally there have to be custom rule sets. Possibly we want some way to annotate source to skip specific warnings. In IDEA/IntelliJ for example, a special comment is used to suppress inspections. Something like:

//noinspection deprecation
final Yaml yaml = new Yaml(...);

We did something similar for CodePro back in the day.

Thoughts, of course, are welcome!

[alan-knight]

Annotating seems likely to be tedious and take up a lot of space in the source code. I don't know that I have any great ideas. One thought is that the rule in #27 seems like a performance type rule. So maybe it would adequate to have a group of rules related to possible performance improvements, I don't run them all the time, but when I do I can put up with some false positives. But I think it will take some experimentation.

[zoechi]

When I have a configuration file at package level to opt in/out of some rules, I find annotations quite handy to define exceptions of these general rules.
Annotations could be applied for different scopes (library, top level declarations, class, methods)
Don't know about expressions though.

[pq]

@zoechi I spun off #44 to brainstorm on source annotations.

[seaneagan]

Should it be possible to disable DO / DON'T rules? I would say no, since that would drastically limit the value of having the DO / PREFER distinctions in the first place. Also, complaints about not being able to disable a given DO / DON'T rule may help determine rules that should actually be PREFER / AVOID.

[zoechi]

I don't think there should be any hard limitations.
If I have a reason to do something in a certain way and I can't get rid of the warning/hint by configuring exceptions these useless warnings sum up until it's too burdensome to look for relevant warnings at all and then it becomes easier to not use the linter at all.

[seaneagan]

If there are good reasons to violate a DO/DON'T rule, then it should instead be PREFER/AVOID. I guess it just depends on whether we can agree on what "good reasons" are... probably not in all cases, so maybe you're right, but I don't think it hurts to at least try at first.

[zoechi]

There might be no good reasons just before you publish but there sure are good reasons during development.

[pq]

Closing this one out in favor of more targeted follow-ups.