Open straight-shoota opened 7 months ago
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.
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.
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):
@sanks02 False positive you've mentioned was fixed in #443
Quoting @Blacksmoke16 from https://github.com/crystal-ameba/ameba/issues/447#issuecomment-1892747306
I think this is quite similar to the considerations about the Crystal formatter rolling out new formats (c.f. https://github.com/crystal-lang/crystal/issues/13002). The formatter is tied to Crystal releases. Ameba on the other hand has more freedom about chosing when to release new rules. How exactly that can be utilized, is up for discussion.
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.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.