Re: [Codenarc-user] What do you think of merging rulesets?
Brought to you by:
chrismair
From: Chris M. <chr...@ea...> - 2011-08-08 00:15:55
|
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 <http://evgeny-goldin.com/> |