Linter Configurability #7

Closed
pq opened this Issue Feb 4, 2015 · 9 comments

Comments

Projects
None yet
4 participants
@pq
Member

pq commented Feb 4, 2015

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

This comment has been minimized.

Show comment
Hide comment
@pq

pq Feb 13, 2015

Member

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!

Member

pq commented Feb 13, 2015

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

This comment has been minimized.

Show comment
Hide comment
@alan-knight

alan-knight Feb 17, 2015

Member

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.

Member

alan-knight commented Feb 17, 2015

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

This comment has been minimized.

Show comment
Hide comment
@zoechi

zoechi Feb 18, 2015

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.

zoechi commented Feb 18, 2015

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

This comment has been minimized.

Show comment
Hide comment
@pq

pq Mar 8, 2015

Member

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

Member

pq commented Mar 8, 2015

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

@seaneagan

This comment has been minimized.

Show comment
Hide comment
@seaneagan

seaneagan Mar 11, 2015

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.

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

This comment has been minimized.

Show comment
Hide comment
@zoechi

zoechi Mar 11, 2015

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.

zoechi commented Mar 11, 2015

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

This comment has been minimized.

Show comment
Hide comment
@seaneagan

seaneagan Mar 11, 2015

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.

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

This comment has been minimized.

Show comment
Hide comment
@zoechi

zoechi Mar 11, 2015

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

zoechi commented Mar 11, 2015

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

@pq

This comment has been minimized.

Show comment
Hide comment
@pq

pq Jun 21, 2018

Member

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

Member

pq commented Jun 21, 2018

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

@pq pq closed this Jun 21, 2018

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment