Re: [Codenarc-user] What do you think of merging rulesets?

[Evgeny G. <ev...@gm...>]

Yes, my "codenarc.txt" is now down to <http://goo.gl/iSyD2>:

ruleset {

    description 'Gradle plugins CodeNarc RuleSet'

    ruleset( "
http://codenarc.sourceforge.net/StarterRuleSet-AllRulesByCategory.groovy.txt"
) {

        DuplicateNumberLiteral   ( enabled : false )
        DuplicateStringLiteral   ( enabled : false )
        BracesForClass           ( enabled : false )
        BracesForMethod          ( enabled : false )
        BracesForIfElse          ( enabled : false )
        BracesForForLoop         ( enabled : false )
        BracesForTryCatchFinally ( enabled : false )
        JavaIoPackageAccess      ( enabled : false )
        ThrowRuntimeException    ( enabled : false )

        AbcComplexity         ( maxMethodComplexity : 70  )
        LineLength            ( length              : 180 )
    }
}

Beautiful. Thanks again, Chris!


On Mon, Aug 8, 2011 at 03:15, Chris Mair <chr...@ea...> wrote:

> Hi Evgeny,****
>
> ** **
>
> I think you can already do most, if not all, of what you are requesting.**
> **
>
> ** **
>
> I just tested using this ruleset:****
>
> ** **
>
> *ruleset {*
>
> * *
>
> *    description 'A Sample Groovy RuleSet'*
>
> * *
>
> *    ruleset("
> http://codenarc.sourceforge.net/StarterRuleSet-AllRulesByCategory.groovy.txt")
> {*
>
> * *
>
> *                BracesForClass(enabled:false)  // Map syntax for setting
> properties*
>
> * *
>
> *                BracesForForLoop {                         // Closure
> syntax for setting properties*
>
> *                                enabled = false*
>
> *                }*
>
> *    }*
>
> *}*
>
> ** **
>
> And it applies ALL of the rules minus the two that I disabled. ****
>
> ** **
>
> That being said, I would not recommend referencing the “StarterRuleSet”
> from the CodeNarc site because, as you mentioned, its contents change
> immediately with each new release (and possibly even at other times) and
> would break your builds. So, perhaps you would substitute something like
> “MyDefaultCodeNarcRuleSet.groovy”.****
>
> ** **
>
> I’m not sure I understand what you mean when you refer to the “first set”
> and “second set” of rules. But the above example illustrates the recommended
> approach for having a global/default ruleset and allowing projects/teams to
> customize it for a specific codebase. And any property values set in this
> ruleset override properties from the “default” ruleset that it includes (the
> “StarterRuleSet..” in this case).****
>
> ** **
>
> I don’t have a great answer yet for how to migrate to the new version of
> CodeNarc, when more rules become available. In my case, I select the new
> rules that I want to include and ignore or disable the ones I don’t. I
> wonder how useful it would be to include a list of new rule names for each
> new release, suitable for copy-paste into an existing ruleset?****
>
> ** **
>
> Chris****
>
> *From:* Evgeny Goldin [mailto:ev...@gm...]
> *Sent:* Sunday, August 07, 2011 5:42 PM
> *To:* cod...@li...
> *Subject:* [Codenarc-user] What do you think of merging rulesets?****
>
> ** **
>
> Hi,
> ****
>
> Today, I keep a copy of StarterRuleSet-AllRulesByCategory.groovy.txt<http://codenarc.sourceforge.net/StarterRuleSet-AllRulesByCategory.groovy.txt> in
> each project with some modifications where rules are disabled or tuned to
> match project preferences.****
>
> It's not very convenient since I need to update this large file for every
> new CodeNarc version, merging new rules added by CodeNarc and existing rules
> configured locally.****
>
> ** **
>
> Would it better if one could reference to:****
>
>    1. Default (probably remote) set of all rules like the one available on
>    the Web today.
>    If one decided to reference the default ruleset on CodeNarc site then
>    he should be aware of a need to upgrade CodeNarc version immediately when a
>    newer version is released as the default ruleset contains new rules,
>    not recognized by older CodeNarc (or we can ask CodeNarc not to fail on
>    unknown rules - this will make it more friendly and "forward compatible").
>    ****
>    2. Local set of rules, overriding the default set for any collision by
>    commenting out rules, disabling them (see below) or changing their
>    configuration.****
>
> ** **
>
> I understand that when rule is commented out in the second set, then it
> simply doesn't exist and if it's defined in the first set then it's enabled.
> ****
>
> But .. it would be nice if CodeNarc could see the rule is actually
> "disabled" in the second set. May be some new syntax for disabling rules can
> be added if commenting them out makes it harder.****
>
> Like a general "enabled" property for all rules and then one could write *"BracesForClass
> { enabled = false }"* in the second local set.****
>
> ** **
>
> I also see with 0.15 if first ruleset contains *"LineLength { length =
> 120 }"* and second  *"LineLength { length = 160 }"* then first value (120)
> is still used by CodeNarc.****
>
> ** **
>
> So .. what do you think of merging rulesets?****
>
> ** **
>
> ** **
>
> Warm regards,****
>
> Evgeny****
>
> evgeny-goldin.com****
>
> ** **
>