Avoid annoyance from new rules about ameba HOT 4 OPEN

I disagree, this argument has been based on a false assertion of high false positive rate of UselessAssign rule.

Not really, this is just the latest occurrence. In the past there was Lint/NotNil, and the change in all the Naming/* rules. It just feels like a lot of the rules are becoming more subjective. Plus with them being enabled by default, it forces the users to conform, or disable the rules.

I don't have any strong feelings around a way forward, but one idea that comes to mind is introducing new rules, keeping them disabled, then at some point in the future, do a new major release that changes the default rules.

EDIT: Another idea is having some sort of tiered rule system. Where tier 1 can be the most useful objective rules, then tier 2 gets a bit less objective, but still conforms to convention, and tier 3+ are Ameba's opinionated rules.

from ameba.

@sanks02 False positive you've mentioned was fixed in #443

from ameba.

But in general, I think it would be very helpful to avoid required user interaction every time a new rule is added. That's especially if the rule has a high rate of false positives (such as Lint/UselessAssign). That just keeps annoying users.

I disagree, this argument has been based on a false assertion of high false positive rate of UselessAssign rule. Yes, there were several, due to the recent changes, yet this doesn't constitute this rule as having "high rate of false positives".

Maybe for a project with existing ameba configuration, all rules that have been added since the version that generated the ameba config could be disabled by default? I.e. if I have a config from ameba 1.6, ameba will only consider rules from 1.6 until I explicitly upgrade to a new version and ruleset.

This would mean an extra DX hassle which I'd like to avoid. Let's think about this more.

from ameba.

I would note that I'm having the same issue.

Though I think it predates Ameba. Here is what is disabled in .rubocop.yml in one of my Ruby projects:

Metrics/AbcSize:
  Enabled: false

Metrics/BlockLength:
  Enabled: false

Metrics/ClassLength:
  Enabled: false

Metrics/CyclomaticComplexity:
  Enabled: false

Metrics/MethodLength:
  Enabled: false

Metrics/ModuleLength:
  Enabled: false

Metrics/ParameterLists:
  Enabled: false

Metrics/PerceivedComplexity:
  Enabled: false

Minitest/MultipleAssertions:
  Enabled: false

Rails/CreateTableWithTimestamps:
  Enabled: false

Rails/DangerousColumnNames:
  Enabled: false

Rails/FindEach:
  Enabled: false

Rails/I18nLocaleTexts:
  Enabled: false

Rails/Pluck:
  Enabled: false

Style/Documentation:
  Enabled: false

Style/EmptyCaseCondition:
  Enabled: false

I often have to disable a couple new rules when updating RuboCop.

Here's what .ameba.yml looks like in one of my projects:

Documentation/DocumentationAdmonition:
  Enabled: false

Lint/UselessAssign:
  Enabled: false

Metrics/CyclomaticComplexity:
  Enabled: false

Naming/BlockParameterName:
  Enabled: false

Three of these were added in the latest minor release, with Lint/UselessAssign having a false positive here (see IHDR usage):

• https://github.com/phenopolis/pluto/blob/53b7ec2adcc7b23088a26b9f9a7c511911bf1b59/src/pluto/format/binding/lib_spng.cr#L10-L12
• https://github.com/phenopolis/pluto/blob/53b7ec2adcc7b23088a26b9f9a7c511911bf1b59/src/pluto/format/binding/lib_spng.cr#L68-L76
• https://github.com/phenopolis/pluto/blob/53b7ec2adcc7b23088a26b9f9a7c511911bf1b59/src/pluto/format/png.cr#L11-L27

from ameba.